RE: rsa-sha2-256/512: handling of incorrect signature encoding

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

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.