Hi Paul,
At 09:56 AM 15-04-2025, Paul Wouters wrote:
I don't think you can state that a draft is not a "specification" as per
"Specification Required".
The issue which the Document Shepherd and I discussed was whether an
Internet-Draft is a formal specification of the IETF.
RFC 2418, Section 7.2, states that: "It is stressed here that
Internet-Drafts are working documents and have no official standards
status whatsoever". RFC 2026, Section 2.2, states that: "An
Internet-Draft is NOT a means of "publishing" a specification;
specifications are published through the RFC mechanism described in
the previous section."
Either my reading is wrong, incorrect, misleading, etc. or there may
be an issue.
The DE should verify the specification is clear, is not a duplicate,
is functionally different from existing registrations, etc. They have no
power to just "dislike and refuse" nor "like despite flaws". So I am not
sure why you believe the DE would be doing "much more" than DE's from
the mediate type registry.
Sorry, I guess I wasn't clear. I was not focusing on whether an
designated expert has the power to just "dislike and refuse" nor
"like despite flaws".
Additionas to this registry would be based on new types of secrets to be
optionally exported for debugging. It would not add new hooks to the TLS
protocol, nor add "new ways". Eg I don't think you could add a HTTP POST
method to this IANA registry for nationstate logging of secret keys.
There are IETF working groups discussing post-quantum
cryptography. From what I understand, and I could be wrong, the
point of adding those "quantum-resistant" algorithms is to improve
security. Now, I see a registry being proposed to reference
proposals for logging secrets. In my opinion, and I am open to being
corrected, it defeats the purpose of having those "quantum-resistant"
algorithms. In addition, there isn't any requirement for the
designated expert to ensure that the requests which they approved are
aligned with RFC 7258.
This document doesn't instruct nor compell you to give "that up".
That document may not say that. The mechanisms used to make a
determination about the registration requests takes the average IETF
participant out of the approval loop.
I don't understand what you would want to have added here. It is a
simple mapping of new secret material in protocol or protocol extensions
to a new environmental variable. The DE will check whether the secret
computation is a real secret (and worth producing a debug value for) and
whether the suggested environment name makes sense in that context. But
this seems rather obvious to me.
It is not about what I would like to be added into the draft. I
pointed to a section of RFC 8126, namely Section 4.5, and quoted the
requirements from that document. My reading of RFC 8126 is that the
requirements are also applicable in the case of draft-ietf-tls-keylogfile-03.
I am not doubting your word that some of the verifications which a
designated expert makes may be obvious to you. It might not be that
obvious to some other person.
Based on the numbers presented in the TLS WG meeting, I thought this
document had broad consensus of the community. I had forgotten that Sean
would confirm this on the list at Stephen's request.
I'll say okay to the above so as to put that matter to me.
I have just added two weeks to the IETF LC, and will send a reminder
when this WGLC is over to remind people the IETF LC is still going for
a few more weeks. This will bring the timing of WGLC and IETF LC in line
with normal processing. Let me know if that is not satisfactory to you.
Thank you for doing the above. I asked the Document Shepherd to ask
the Area Director who is responsible for the working group whether
he/she could consider sharing his/her Area Director evaluation of the
proposal. I would be grateful if you could consider doing that.
Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
