On Feb 22, 2016, at 12:47 AM, Niels Möller <nisse%lysator.liu.se@localhost> wrote: > I've now posted a first version, > https://www.ietf.org/id/draft-nisse-secsh-aead-00.txt. I was advised by > a collegue with a bit more ietf experience to include one concrete AEAD. > So I added chacha-poly1305, to define something which is actually > implementable. Looks good. 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. This approach avoids either breaking the AEAD abstraction, or having to “misuse” an AEAD as a stream cipher. It improves efficiency by ensuring that the AEAD cipher primitive needs to be invoked per packet, not twice. It improves security by ensuring that no packet-length field is ever used in any way by the receiver before it’s been cryptographically authenticated. In particular, it eliminates the classic vulnerability where an attacker can corrupt the length bits to make the length appear large and cause the receiver to hang indefinitely on a long socket read(). The obvious, and I think only, key question is how the sender “knows” in advance what length to promise for the next record, given that it can’t really see into the future. But there are plenty of reasonable answers, from dead-simple to somewhat smarter. A dead-simple sender could always send packets in pairs, the first being minimum-size (e.g., zero-payload-bytes) but indicating the second one’s length, the second packet containing the useful variable-length payload. A slightly smarter sender could recognize when it has a lot of data buffered (e.g., during file transfer) and send runs of large packets and “promise” a minimum-sized one only when its tx buffer runs dry. A sender that pads for traffic analysis protection could always pad packets to the same length, and thus trivially knows what to “promise” in every packet. A smarter sender with traffic analysis protection could pad packets to *multiples* of the same length opportunistically when there is enough data in the tx buffer; that’s more CPU- and bandwidth-efficient but to an adversary it still looks indistinguishable from N of the shorter packets. There are more details in the relevant E-mails I posted back in December on the TLS list: - https://www.ietf.org/mail-archive/web/tls/current/msg18524.html - https://www.ietf.org/mail-archive/web/tls/current/msg18710.html Cheers Bryan
Attachment:
smime.p7s
Description: S/MIME cryptographic signature