Re: [TLS] Choice of Additional Data Computation

[Eric Rescorla <[e-mail]>]

On Fri, Apr 24, 2020 at 11:17 AM Hanno Becker <[e-mail]> wrote:

> 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.
>

Yes, that's correct. But you can't swap header formats.


> 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 (?).
>

I don't think that's at all obvious. Again, the problem with the
pseudo-header is you are authenticating some abstract information, *not*
what is actually on the wire, and that allows the attacker to manipulate
what's on the wire undetected. We have no analysis for the impact of that.


-Ekr


> 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.
>