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
