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 On Behalf Of Ilari Liusvaara
> Sent: Monday, November 28, 2022 11:11 AM
> To: TLS List
> Subject: [EXTERNAL] Re: [TLS] Call for adoption of
> draft-thomson-tls-keylogfile
>
> On Mon, Nov 28, 2022 at 07:02:20PM +, 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=05%7C01%7CAndrei.Popov%40microsoft.com%7C4d4695c5433c4186eed608dad17465a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052595136932049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0WqfX2eGL7cXMwCbYEOegEEnpRNXtdyFcDC3QBjMOe8%3D=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
