On Feb 23, 2016, at 7:56 AM, Niels Möller <nisse%lysator.liu.se@localhost> wrote: > Bryan Ford <brynosaurus%gmail.com@localhost> writes: > >> I see that in 3.1 on “Encrypting the packet length”, you’ve suggested >> the same approach as one of the earlier approaches I suggested a while >> ago in the corresponding TLS discussion. That’s a reasonable approach >> and I think would work, but I wanted to make sure you’re aware of >> another alternative that I’ve come to think is both cleaner and safer: >> just embed the length of the next packet within the normal >> AEAD-encrypted payload of its immediately prior packet. > > Thanks for the update. > > This could make a lot of sense for a new protocol or for a larger > protocol update. But I think adding the length field to the preceding > packet is a too large structural change of the ssh protocol to do just > to support AEAD ciphers. 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. No one will be able to decrypt a new AEAD-encrypted record anyway unless it understands the new AEAD spec; it wouldn’t be that hard for it to interpret the encrypted contents of that record a bit differently at the same time. This AEAD-induced incompatible change thus presents a natural point in time in which to introduce other (minor) changes relatively painlessly in the encrypted content of those records, without introducing any “new” negotiation mechanisms. Just specify that all legacy (non-AEAD) ciphers always use the “old” internal packet format, and new (AEAD) ciphers always use the “new” internal packet format. Deferring useful record format changes until the next major protocol version, in contrast, creates the risk that implementations of the next major protocol version will need to support at least (a) legacy non-AEAD ciphers using the old format, (b) AEAD ciphers using the old format, and (c) AEAD ciphers using the new format. That’s more moving parts, more protocol complexity, and greater risk of security bugs compared with just being able to deal with situations (a) and (c) alone. Just some tradeoffs to be considered anyway. B
Attachment:
smime.p7s
Description: S/MIME cryptographic signature