> While we're dropping wishlist items for SSH v.3, here's one of mine: > > Key exchange negotiates an AEAD rather than a cipher and a MAC > separately, and does so from a greatly trimmed set of options. E.g. > AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode. > > IMO the AEAD primitive is the right metaphor for the security > properties of the SSH transport protocol. Removing the large > cartesian product of ciphers x MACs will make testing faster and > binaries smaller too. I agree. I believe there is opportunity to deprecate all pre-AEAD modes, if there is interest on doing that. I believe the experience with TLS is that no non-AEAD mode has the properties that we desire. Generally, I believe the experience is that you cannot negotiate cipher and MAC separately, it has to be done together. Maybe we can draft something together, and bring it to the curdle IETF WG, it would be in scope of that process. Looking at these registries: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-17 http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-18 I believe it would be possible to mark all as obsolete/historic, except for a list of a few known good combinations that we can actually recommend. As far as I can tell that list would include: aes128-ctr aes256-ctr chacha20-poly1305 (whatever that turns out to be) umac-* (same here..) hmac-sha1 (for older ciphers only?) hmac-sha2-256 (for older ciphers only?) Any others? I'm not sure what to make of the RFC 5647 AES-GCM mode. Nobody seems to implement that. /Simon
Attachment:
pgpka8eRDWQhC.pgp
Description: OpenPGP digital signatur