> On Apr 11, 2025, at 11:50 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > > > 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 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/ > _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
