[TLS] Re: Publication has been requested for draft-ietf-tls-keylogfile-03

[Sean Turner <[e-mail]>]

> On Apr 11, 2025, at 11:50 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> On 11/04/2025 16:40, Sean Turner wrote:
>>> On Apr 9, 2025, at 8:00 PM, Stephen Farrell
>>> <[e-mail]> wrote: On 03/04/2025 14:42, Stephen
>>> Farrell wrote:
>>>> On 03/04/2025 14:35, Sean Turner via Datatracker wrote:
>>>>> Sean Turner has requested publication of draft-ietf-tls- keylogfile-03 as Informational on behalf of the TLS working
>>>>> group.
>>>>> Please verify the document's state at https://
>>>>> datatracker.ietf.org/ doc/draft-ietf-tls-keylogfile/
>>>> Hang on - where was the outcome of the WGLC declared or summarised by the chairs? Where are the minutes for the IETF-122
>>>> meeting? I think you're skipping process steps here in a way
>>>> that ought not be done, esp when there have been objections to this draft. (And I think I already asked that the poll at the
>>>> meeting not be used as a declaration of consensus.) Please
>>>> correct. I object to decisions not being made on the list when
>>>> there is contention.
>>> I got no response from chairs or AD on or off list to the above.
>>> Seems like bad form to me but maybe people were too busy.
>>> I note that despite my request/objection, the IETF LC for this has
>>> now been issued. I've objected there too. [1]. I see that SM also
>>> had process comments on this too. [2]
>>> I do plan to appeal should this document not be sent back to the
>>> WG to confirm whether or not there is WG consensus to publish.
>>> (And publishing as-is is wrong of course:-)
>>> Cheers, S.
>>> [1] https://mailarchive.ietf.org/arch/msg/last-call/
>>> KFXyZbe_hi-0OjCtvORwyJm_wpo/ [2] https://mailarchive.ietf.org/arch/
>>> msg/last-call/fLGvbWNGBhux9c6crFJ1ZioKmLg/
>> Stephen,
>> The minutes have now been posted; see [0]. Joe posted them for
>> internal review, and I got my wires crossed that the minutes were
>> not also published to the datatracker.
> 
> Ack.
> 
>> I have updated the Shepherd Write-Up and brought your (and others)
>> continued objections to progressing this draft. Likewise, I have
>> discussed this with our AD at length. The points I believe you have
>> made align the way (beyond don’t publish, this is a bad idea) are:
>> 1. Strong Caveats/Warnings: When draft-thomson-tls-keylogfile was up
>> for adoption, you were okay adopting it as long as there were
>> sufficient warnings. The Security Considerations section includes
>> much more text and an Applicability Statement section was added,
>> which in particular notes this mechanism “MUST NOT” be used in
>> production systems. When -ech-keylogfile, I believe there were more
>> objections, but not a lot of support for more text. Now the drafts
>> are combined, the text in the Security Considerations has been
>> expanded to also include ECH and the Applicability Statement
>> remains. Likewise, a PR has been landed and will appear when -04 is
>> published that adds words specifically about the compilation issue
>> [1]. As both drafts completed WGLC independently and now the draft
>> is a combo, this point seems settled.
>> 2. -ech-keylogfile is not needed because ECH is new. There were
>> people who implemented ECH at scale who spoke in support of -ech-
>> keylogfile. Also, -ech-keylogfile made it through WGLC; the only new
>> comment beyond “make the warnings stronger and bigger” was to merge
>> the draft together because it was odd that -ech-keylogfile was
>> creating a registry for a draft so newly in the RFC editor’s queue.
>> 3. Merging: During -ech-keylogfile, Rich suggested we merge it. I
>> noted that that was going to happen when I closed out that WGLC.
>> There were no objections. I noted that that merge had completed when
>> -tls-keylogfile-03 was published; again, no objections to the
>> initial note.
>> 4. Specification Required vs IETF Review: This WG published RFC 8447
>> and -rfc8447bis is nearing completion. As you know, these documents
>> set the registration requirements for almost all of the registries
>> to Specification Required, which also implies expert review. This is
>> true for the Cipher Suite & Support Groups. If the concern is about
>> something slipping by the DEs, then we have bigger problems. The
>> registration list is public [2], the DEs are known (Yoav, Rich, and
>> Nick), and the DEs can raise registrations with the WG and have
>> previously reported on registrations [3].
> 
> The above is a pretty fair summary, but not quite 100% (which is
> natural enough) - IMO item #4 is by far the worst  aspect of
> publishing as-is; this does differ from other registries as every
> new thing added to this one is a new way to exfiltrate (a bad
> thing when done outside debugging which we know will happen),
> whereas with other registries adding a bad thing is very much
> the exception (e.g. NULL ciphers are very rare). I think we would
> be far better off with IETF review if we do have to hold our
> noses and create this registry.
> 
>> As you note I did not close out that WGLC; I should have, I will
>> send a message in response to the WGLC thread referring to this
>> message.
>> While I know you would prefer to not use the informal poll we took
>> at the IETF 122 session because it does not support your position it
>> is nonetheless telling. But because I forgot about the change to add
>> more compilation constraints in the Applicability Statement and we
>> should confirm the discussions at IETF on list, we will get a new
>> version posted and re-run the confirmation about progressing the
>> draft call noting that there was strong consensus with some vocal
>> opposition. Stay tuned.
> 
> That plan should fix the process glitches, thanks. (Mind you,
> having 4 people, one of whom was up at 4am local, indicate a
> preference for something like do-not-publish might well be argued
> to indicate that there is not a strong consensus.)
> 
> Thanks,
> S.

Yep that’s the plan fix ‘em. And, we are waiting on the -04 version. I mean technically I can submit a new version, but I will let the authors do so.

spt

>> I have replied to S. Moonesmay.
>> Cheers, spt
>> [0] https://datatracker.ietf.org/doc/minutes-122-tls-202503200230/ [1] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-
>> keylogfile&url_2=https://tlswg.github.io/sslkeylogfile/draft-ietf-
>> tls-keylogfile.txt [2] https://mailarchive.ietf.org/arch/browse/tls-
>> reg-review/ [3] https://datatracker.ietf.org/doc/minutes-119-
>> tls-202403182330/
>