On Apr 9, 2025, at 6:32 PM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
Hello, At 08:09 AM 09-04-2025, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The SSLKEYLOGFILE Format for TLS'
<draft-ietf-tls-keylogfile-03.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2025-04-23. Exceptionally, comments may
The document shepherd write-up was last changed on 2 April. The write-up states that it is dated 4 July 2022. One of those dates is inaccurate.
The 4 July 2022 date is the date of the template; it’s the same for template that you pull up. I found a "call for adoption" on 28 November 2022 in the TLS working group mailing list archives. I could not find the working group last call announcement. I could not find an announcement regarding the conclusion of the working group last call. I could not find any record of an Area Director review before the publication request.
Merged draft WGLC here: Reminder here: There were a vote during a meeting according to the document shepherd. The minutes were published on 3 April. That is the same day on which the draft was submitted to IESG for publication.
Yes that was my bad I fixed that up. It looks like decisions are taken at meetings and a participant who did not attend those meetings is not given appropriate notice or an opportunity to comment.
The draft states in Section 1 that "Debugging or analyzing protocols can be challenging when TLS [TLS13] is used to protect the content of communications." I assume that this SSLKEYLOGFILE feature may help people implementing and analyzing TLS. There isn't any "Updates" to the TLS specifications. Is it to mitigate pervasive surveillance (RFC 7258) or for some other reason?
The IETF has not been uniform about the use other than the Updates header. Sometimes it’s hint to others that a draft might be of interest; I refer to this as a breadcrumb update ;) The other times an Update header has been applied is when somebody thinks there is an expectation that all implementations will support the draft. There are other times when there is no update header at all because not every draft needs to be linked back of the base document; there are hundreds of these examples. This I-D includes no Updates header. This draft intends to create of a registry (Section 4) which will be managed through the "Specification Required" procedure. The specification is expected to be a formal public specification. The draft states that "It is sufficient to have an Internet-Draft". Does it mean that an Internet-Draft is a formal public specification of the IETF?
I will note this draft uses the procedures from RFC 8447, a product of this WG. I will not comment on the meta question of whether an Internet-Draft is a formal specification of the IETF, but in some of the TLS registries an Internet-Draft is sufficient as was decided by IETF consensus.
The intended policy for the registry (Section 4) is quite strict as it combines "Specification required" with "Expert review". Is there any justification for such a strict policy given that the SSLKEYLOGFILE feature is described as being for debugging and analyzing TLS v1.3, including "TLS Encrypted Client Hello"?
Again, this draft follows the RFC 8447 procedures applied to almost all of the registries; I believe the ones we didn’t apply it to was done because of scarcity of code points. Remember Specification Required implies Expert Review. I also would not consider "Specification Required" with "Expert Review” as strict; the DEs can say yes/no, then can point out drafts to the WG there are any questions - just like other times.
spt Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
