> It doesn't seem straightforward to extrapolate from that case since the > 'pseudo-header' > and on-the-wire header are the same here, as TLS 1.3 doesn't have any > header > data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, > various > fields can be dropped or shortened, such as the length, sequence number, > CID. >
It's certainly true that we can't extrapolate the security of DTLS from the existing proof for TLS. In the first place, the threat model is different because in DTLS we need to tolerate dropped/out-of-order packets. Nevertheless, I think the general principle of "authenticate all the bits" is the right way to go here, unless there's a compelling reason not to. In the case of TLS 1.3, authenticating the entire header (including the length, opaque type, and legacy record version) allowed us to effectively ignore most of the header details in the security proof [1]: all we cared about is that the header correctly encodes the length of the next ciphertext to decrypt. We might be able to provide a similar argument for DTLS 1.3. In particular, I'm betting that it doesn't matter what the contents of the header are or how long it is, so long as (a) the entire header is part of the AAD and (b) it correctly encodes the length of the next ciphertext. I might be missing something, however. In any case, new definitions are needed (if they don't already exist) and so too a fresh proof. Chris P. [1] https://eprint.iacr.org/2018/634.pdf
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
