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

[Stephen Farrell <[e-mail]>]

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.

> 
> 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/
> 
>