On Fri, Apr 24, 2020 at 11:17 AM Hanno Becker <hanno.bec...@arm.com> 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 - <chrispat...@gmail.com> > *Sent:* Friday, April 24, 2020 6:57 PM > *To:* Eric Rescorla <e...@rtfm.com> > *Cc:* Hanno Becker <hanno.bec...@arm.com>; Hannes Tschofenig < > hannes.tschofe...@arm.com>; tls@ietf.org <tls@ietf.org> > *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. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
