On Sat, 12 Apr 2025, S Moonesamy wrote:
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.
Well, there is an IETF community consensus document, namely BCP 26.
I don't think you can state that a draft is not a "specification" as per
"Specification Required".
The designated experts would be doing much more than the designated experts
for media type requests.
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.
"this features an IANA registry that would allow a DE to expand
the set of ways in which keys could be exfiltrated by TLS
implementations without IETF oversight."
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 actors at my location who have demonstrated the capabilities to
intercept all TLS connections originating from the location.
That suggests they are exfiltrating secret key material from the TLS
server or your device - against your presumed desire. That would be
completely out of scope of this document.
I will not have
any say on those future registration requests which those actors might use.
Again, any future registration requests would not include new transports
to take key material via a new transport off the endpoint.
I don't think that it is a good idea for me to give that up.
This document doesn't instruct nor compell you to give "that up".
The last sentence of the draft states that the IESG designated experts may
provide more in depth reviews. It does not list any criteria for those
reviews. Here's what RFC 8126, Section 4.5, says: "The required
documentation and review criteria, giving clear guidance to the designated
expert, should be provided when defining the registry."
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.
I'll get to the potential procedural issues. I don't remember coming across
a case where there was a working group Last-Call occurred in parallel with a
BCP 9 Last-Call. I would be grateful if you could 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.
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 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.
Paul
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
