Re: AEAD in ssh

Bryan Ford <[email protected]> writes:

> I can understand that position. However, one potentially
> counter-balancing consideration is that the introduction of new
> AEAD-based ciphersuites inherently introduces a new,
> wire-protocol-incompatible “record format” anyway that needs to be
> negotiated.

I agree, but at least it's only a different per-packet transformation.
Having to guess future packet sizes or emit extra packets is much more
than a new record format. I don't think it's a good tradeoff, too much
new complexity for little benefit.

My understanding is that cleartext length fields are believed to be
secure, in that the only thing leaked are message boundaries. And hiding
them using a separate stream cipher is a simple way to stop that leak
(and the benefit of doing that is under debate). In particular, the even
simpler alternative, to apply the AEAD to the 4-byte length field,
including authentication, seems like overkill. 

I think simplicity is essential for making progress here, if we go for a
design of ssh version 3, discussion will never end.

> Deferring useful record format changes until the next major protocol
> version,

I don't expect any need for a new major version of the ssh protocol for
the next one or two decades. It's not too painful to add aead support
(and all other additions of new algorithms have been smooth, as far as I
can tell).

Regards,
/Niels

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