Hiya,
On 11/04/2025 16:40, Sean Turner wrote:
On Apr 9, 2025, at 8:00 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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 workingHang on - where was the outcome of the WGLC declared or summarised by the chairs? Where are the minutes for the IETF-122group. Please verify the document's state at https:// datatracker.ietf.org/ doc/draft-ietf-tls-keylogfile/meeting? I think you're skipping process steps here in a waythat ought not be done, esp when there have been objections to this draft. (And I think I already asked that the poll at themeeting 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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
