I personally have no intention of making this PS (or to otherwise water down recommendations against it).
I do have some interest in doing what can be done to make this less of a hazard. You will see that I took John's suggest to more directly proscribe its use: https://github.com/martinthomson/sslkeylogfile/pull/1 One benefit of moving this under IETF change control is that we can have those conversations about how to manage this better. To Stephen's point, the idea that you might negotiate an extension when this is enabled is an interesting one. I don't think that it needs to be large in order to have the intended effect (if the intended effect is punitive in nature, then that creates certain disincentives around compliance). There are many cases where I think it would be beneficial to have the presence of this known to both entities. The challenge of course is that this is primarily of benefit to the client only - the server cannot unilaterally signal that it has this machinery engaged. (Another thing to note is that the qlog work in the QUIC working group has lesser, but broadly similar properties. It would be good to share what we learn from this exercise.) On Tue, Nov 29, 2022, at 03:22, Andrei Popov wrote: > Does an Informational draft require WG adoption? If the goal isn't to > switch to the Standards track, I have no concerns. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Ilari Liusvaara > Sent: Monday, November 28, 2022 11:11 AM > To: TLS List <tls@ietf.org> > Subject: [EXTERNAL] Re: [TLS] Call for adoption of > draft-thomson-tls-keylogfile > > On Mon, Nov 28, 2022 at 07:02:20PM +0000, Andrei Popov wrote: >> >> I oppose adoption of draft-thomson-tls-keylogfile. The stated goal was >> to find a permanent, discoverable location for this document, other >> than NSS project's repository. Perhaps it's fine to create an RFC for >> this purpose, but then I'd argue that it should be an Informational >> RFC. > > The I-D has: "Intended status: Informational" (for some reason the > datatracker is unable to determine this). > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popov%40microsoft.com%7C4d4695c5433c4186eed608dad17465a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052595136932049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0WqfX2eGL7cXMwCbYEOegEEnpRNXtdyFcDC3QBjMOe8%3D&reserved=0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
