|
> Yeah, so my code does
use "rsa-sha2-256" after all for the auth and sig type,
OK, that sounds right. :-)
> What we actually need is interop test
servers,
I did set up a test server for the new
rsa-sha2-XXX signature types; I posted connection information here, and included
instructions to test both server and client authentication. I was under the
impression that you might have used it, but I’m not sure if you
did.
At this point, the implementation is available in
our published latest release, which can be downloaded and tested free of charge
(though it does require a Windows VM or computer).
> Make it one again, it did use the correct string,
> it was only the mix
of SHA-256 + SHA-1 at the
> same time that would
have caused problems.
That’s a relief. Sounds great. :-)
From: Peter Gutmann
Sent: Tuesday, August 2, 2016 03:07
Subject: RE: rsa-sha2-256/512: handling of incorrect signature
encoding denis
bider (Bitvise) <ietf-ssh3%denisbider.com@localhost> writes: >This is actually exactly contrary to what the current draft says, and what it >has said for 9 months in its latest version. > >If you are sending an rsa-sha2-XXX signature, you cannot set all 3 fields in >the authentication request to "ssh-rsa", because then this makes for a SHA-1 >signature as it was done traditionally, not a SHA-2 signature. To send a >SHA-2 signature, at least one field has to contain "rsa-sha2-XXX". I've looked through my code and saw why it works currently, I assume that if you've negotiated SHA-256 in the client/server hello (keyex) then the auth will also use SHA-256 (it would seem a bit strange to use a strong hash everywhere else in the exchange and then fall back to a weak one for the auth). So in my case unless you use SHA-256 everywhere but then decide to use SHA-1 in the auth, things will work. >The draft specifically says the signature format names are "rsa-sha2-XXX", >but the public key format name stays "ssh-rsa", which it must stay in order >to preserve existing RSA key fingerprints. Yeah, so my code does use "rsa-sha2-256" after all for the auth and sig type, it just wasn't obvious at first glance because the hash is implied. I've made the one-line change to allow use of SHA-256 everywhere but then SHA-1 for the auth. >My strong preference would have been for implementations - especially the >early implementations - to verify this strictly, and to not accept signatures >that depart from this spec. What we actually need is interop test servers, with everyone doing this more or less in isolation (there was nothing to test against when I did this, and for the ECC stuff it wasn't much better, was it you that set up an SSH-ECC server for testing when the draft was published?) you end up with implementations that do all sorts of things. >Unfortunately, we now appear to be in a situation where not only one, but >potentially two implementations depart from the above spec. Make it one again, it did use the correct string, it was only the mix of SHA-256 + SHA-1 at the same time that would have caused problems. Peter. |