Re: [TLS] Choice of Additional Data Computation

[chris - <[e-mail]>]

> 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