Re: AEAD in ssh

Damien Miller <[email protected]> writes:

>> 2. How it interacts with first_kex_packet_follows. 
>
> I don't think the first_kex_packet_follows rules need adjustment if
> mac negotiation is simply ignored for ciphers that are AEAD.

I think it just needs to be a little clearer. You mean that "ignored"
implies "considered a successful guess for purposes of the
first_kex_packet_follows logic", right?

>> 3. If and how to encrypt the length field. 

> IMO this is completely up to the AEAD itself.

Since there isn't a single obvious way to do length encryption, I think
an ssh-aead is a good place to document some reasonable way to do it.
Possibly as a SHOULD (i.e., the spec for each particular AEAD should
stick to this particular way unless there's a good reason not to), but
not a MUST.

>> 4. What the "block size" used for padding purposes (RFC 4253, Sec. 6,
>>    "Binary Packet Protocol") should be. 

> I don't think it makes sense to try to define this for AEAD modes in
> abstract, it's a concrete property of the individual algorithms.

An AEAD algorithm as defined in RFC 5116 has no block size. Do you see
any advantage in making sure that the message size aligns with any block
cipher underlying any aead algorithm? If the alternative is to either
stick with 8 and the original size alignment rules, or to drop the
requirement that sizes align with any block size?

If we want to leave open for using an algorithm-specific block size, I
guess we have to do it like aes-gcm (RFC5647) and align things so that
the size of the aead plaintext input matches that block size, not
counting the length field like for non-aead ciphers. Right?

I think it is quite important to specify this in a uniform way for aead
algorithms. It should be easy to plug in any AEAD adhering to the
interface specified in RFC5116, without having to write new code to
ensure correct ssh packet sizes. (Which is why I'd also like to specify
some general and reasonable way to do length encryption).

> IMO the best approach to the problem is to define the right way to
> negotiate AEAD algorithms in KEX, but specify the AEADs individually.

In principle, I agree. But I think it will make better progress to have
at least one aead in the spec, both to help iron out the details, and to
get some concrete and good aead standardized faster (I don't quite like
gcm).
 
> If I had a time machine then I'd go back to 2000, buy a bunch of
> stocks and then argue that SSH2 should only negotiate complete AEADs
> rather than separate ciphers and MACs.

I don't think the ssh protocol design was controversial at all back
then. E.g, Schneier's Applied Cryptography, the bible at the time,
recommended doing the MAC on the plain text rather than the cipher text.
IIRC.

Regards,
/Niels

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