While I think the approach I suggested for encrypted DTLS headers would work, it does have the downsides of (a) the complexity of managing the hash table of encrypted sequence numbers, and (b) the risk of desynchronization after long bursts of missed packets.
But further discussion with Philipp Jovanovic led me to the realization that the simplest and cleanest solution in the DTLS case would simply be to rely on AEAD ciphers that either support "secret message numbers" or have a "misuse-resistance" property. In particular: - Secret message numbers basically do "precisely what DTLS needs", namely allow a message/record/sequence number to be transmitted under encryption along with the AEAD payload. Secret message numbers are specified as an optional feature for AEAD submissions to the ongoing CAESAR cipher competition (see http://competitions.cr.yp.to/caesar-call.html), and further elaborated in this useful message by DJB in 2013: https://groups.google.com/forum/#!searchin/crypto-competitions/secret$20message$20numbers/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J - Another optional feature that some CAESAR competition submissions have, and *all* are required to document one way or another, is "misuse-resistance". In particular, a misuse-resistant AEAD does not rely on nonce uniqueness for security. With a misuse-resistant AEAD (which we might alternatively just refer to as a "nonceless AEAD"), you can simply move the complete DTLS header from the additional_data field into the plaintext, and leave the sequence number out of the nonce. The sequence number will still be in (encrypted) header and thus available for replay-protection purposes and such, and will automatically ensure that all DTLS plaintexts (and hence all resulting ciphertexts) are cryptographically unique. I'm not proposing necessarily that the "next version of DTLS" (presumably based on TLS 1.3) should *only* allow AEADs that support secret message numbers or misuse-resistance. Rather, I'm proposing that the next DTLS should support at least one such cipher, and that when DTLS negotiates such a cipher, it simply takes advantage of the relevant property to move the DTLS header under encryption. So the upshot is that simply "using relevant AEAD features when available" would seem to take care of the DTLS case completely, with no special fuss or additional complexity. Which means that we can focus on the TLS case now, without worrying about whether and how easily it will translate to DTLS. And given that, for the TLS case I'm inclined to prefer my second proposal, namely just reinterpreting the "length" field to be a "next-record-length" field. This requires no special mucking with the AEAD in TLS either, and no extra complexity at all in TLS implementations that pad to constant record sizes (which I hope many will). For reference, some background pointers misuse-resistant ciphers (definitely not comprehensive): - https://eprint.iacr.org/2006/221.pdf - https://eprint.iacr.org/2015/999.pdf Cheers Bryan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
