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