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
