Re: [TLS] Choice of Additional Data Computation

[Hanno Becker <[e-mail]>]

Hi Chris and Ekr,

> I'm not sure if it's straightforward, but I would note that in TLS 1.3, we did *implicitly* authenticate the length because AEAD provides that, but nevertheless one of Chris's recommendations was to include it in the AAD.

I don't know if this recommendation still holds for DTLS (though Chris' last reply sounds
like it), but DTLS 1.3 currently deviates from it: The length is explicitly authenticated only
for records using header formats which contain the length, while for the most compressed header
form omitting the length one relies on implicit length authentication via AEAD.

> 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]:

If the security analysis shall be agnostic of header details, then in the case of
DTLS 1.3 with its various header formats (https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4)
it sounds to me as if using a pseudo-header containing all header information for AAD would fit better (?).

Best,
Hanno

________________________________
From: chris - <[e-mail]>
Sent: Friday, April 24, 2020 6:57 PM
To: Eric Rescorla <[e-mail]>
Cc: Hanno Becker <[e-mail]>; Hannes Tschofenig <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [TLS] Choice of Additional Data Computation

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.