Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Niels (regarding EXT_INFO):

> But please don't mix that up with the simpler issue
> of algorithm updates.

Yes - this is why I have separated the RFCs, so they can progress, or not progress, independently.


> Note that's what relevant for public key user auth
> isn't really the algorithms supported by the server,
> but the algorithms of the keys which are actually
> authorized for login.

This seems to me the kind of setting that's likely to be enabled or disabled by server-wide policy or algorithm availability, not by per-user configuration. For example, if the server doesn't support rsa-sha2-512, but does support rsa-sha2-256, that's probably going to be server-wide, not user-specific. If the server administrator disabled ssh-rsa due to SHA-1 concerns, that's also going to be server-wide.


> It makes some sense to filter available keys depending
> on what the server supports, but I don't think it will
> make much of a practical difference.

Consider that you have a server that supports rsa-sha2-256, but not ssh-rsa. You have a client who's inclined to try rsa-sha2-512 first, and rsa-sha2-256 next. Or the other way around.

Without EXT_INFO, you spend:
- one round-trip in SERVICE_REQUEST and SERVICE_ACCEPT
- one round-trip in initial request with rsa-sha2-512 signature, rejected
- one round-trip in next request with rsa-sha2-256 signature, accepted

Total: 3 round-trips. This might be 0.6 seconds over the Pacific (200 ms per round-trip), or 6 seconds over a satellite link (2s per round-trip).

With EXT_INFO, you spend:
- half a round-trip waiting for server's EXT_INFO, which comes with NEWKEYS
- one round-trip in request with rsa-sha2-256 signature, accepted

Total cost: 1.5 round-trips. This might be 0.3 seconds over the Pacific, or 3 seconds over a satellite link.
    
Now consider a future scenario where we add rsa-sha3-256 and rsa-sha3-512. :) Now you might be spending 5 round-trips guessing the right algorithm without EXT_INFO. Whereas with EXT_INFO, you are done in 1.5 round-trips. These 5 round-trips might be 1 second over the Pacific, or 10 seconds over a satellite link.

With EXT_INFO, we have a flat cost that does not increase. Without EXT_INFO, cost may not look so bad right now (say 3 round-trips if second guess is right); but future round-trip cost increases.


----- Original Message -----
From: Niels "Möller" 
Sent: Friday, November 13, 2015 02:16
To: denis bider 
Cc: ietf-ssh%netbsd.org@localhost ; Damien Miller ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.farrell%cs.tcd.ie@localhost ; jon%siliconcircus.com@localhost ; Peter Gutmann ; Max Horn 
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

> It seems to me that SSH needs a proper extension mechanism to avoid
> version-string-based hacks and other kinds of hacks.

Maybe. But please don't mix that up with the simpler issue of algorithm
updates.

> - Does not make signature algorithm information available in time for
> the client's first user auth request. This costs a round-trip if the
> client's first guess is incorrect.

Note that's what relevant for public key user auth isn't really the
algorithms supported by the server, but the algorithms of the keys which
are actually authorized for login. It makes some sense to filter
available keys depending on what the server supports, but I don't think
it will make much of a practical difference.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.