Thank you, Chris, for the pointers! I wasn't aware of the paper nor the GitHub issue.
It's such a coincidence that I'm reading Shrimpton's 2004 paper on IND-CCA3! I noticed you are one of the authors of the paper you cited. That makes it even more interesting :) Katz and Lindell (Third edition) present the authenticated-encryption experiment, which I realised is what Shrimpton calls IND-CCA3. And that triggered a few questions about TLS 1.3's choices. Thanks again. I shall read the paper. Regards Devi Prasad On Thu, 15 Aug, 2024, 21:59 Christopher Patton, <cpat...@cloudflare.com> wrote: > HI Devi, > > This decision was made in large part due to the (arguably too > conservative) analysis in this paper: https://eprint.iacr.org/2018/634 > Here is the issue where it was discussed: > https://github.com/tlswg/tls13-spec/issues/1145 > > I don't know why the AD was empty ... I'd also be very interested in this > history. > > Chris P. > > On Thu, Aug 15, 2024 at 7:53 AM devi prasad <dpras...@gmail.com> wrote: > >> I've been reading about TLS 1.3, referring to RFC 8446, simply out of >> technical curiosity. >> >> >> While trying to figure out a few details from the mail archive, I >> couldn't find conversations about the decision to include "additional >> data" (AD) in the AEAD scheme. Trawling through the drafts I noticed >> something interesting - AD went from being an empty input to being the >> record header, from draft 24 to draft 25, in the span of about 15 days. >> >> It's obvious I've no access to the technical conversations that must have >> happened. >> >> Can someone help me understand the reasons for including AD only in the >> last few iterations of the draft. Why was AD an empty input, initially? >> Are there any threads on the mailing list that I've missed? >> >> Thank you very much. >> Devi Prasad >> >> >> Here's the reference for the text in drafts 24 and 25: >> >> draft-ietf-tls-tls13-24, February 15, 2018 >> >> page 82 >> >> Section 5.2. Record Payload Protection >> >> "... the additional data input is empty (zero length)." >> >> draft-ietf-tls-tls13-25, March 02, 2018 >> >> page 82 >> >> 5.2. Record Payload Protection. >> >> "... and the additional data input is the record header. >> >> I.e., >> >> additional_data = TLSCiphertext.opaque_type || >> >> TLSCiphertext.legacy_record_version || >> >> TLSCiphertext.length >> >> ... " >> >> >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
