[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Steven Valdez <[e-mail]>]

On Fri, Jul 26, 2024 at 3:25 AM Bob Beck <bbe=[e-mail]>
wrote:

>
>
> On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho <yrosomakho=
> [e-mail]> wrote:
>
>> Thank you for the feedback, Andrei.
>>
>> Yes, it is intended to stay on the informational track as an extension
>> to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the
>> keylogfile draft - for instance in the applicability statement it is worded
>> that "this mechanism MUST NOT be used in a production system". Happy to add
>> stronger wording if that helps.
>>
>
> No matter what your opinion on standardizing SSLKEYLOGFILE,
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not
> contain this MUST NOT guidance as in this draft.
>
> This guidance does appear to be included in the base draft under "1.1
Applicability Statement".


> MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality
> that is not present for the rest of specification calls into question how
> an application developer shipping SSLKEYLOGFILE functionality in an
> application is supposed to follow this guidance. Is only this portion of
> the functionality supposed to be removed in "production"
>
> It seems to me like if this is what the IETF wants to advise, This advice
> is being given in the wrong draft.
>
> -Bob
>
>
>>
>> The ultimate goal is to simplify adoption of ECH for both developers of
>> TLS software and implementers. Without a standard approach to
>> troubleshooting every developer has to build an individual set of bespoke
>> troubleshooting tools. Ability to inspect ECH negotiation in off the shelf
>> tools such as Wireshark during development or tests would significantly
>> help adoption.
>>
>>
>> Best Regards,
>> Yaroslav
>>
>> On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov <Andrei.Popov=
>> [e-mail]> wrote:
>>
>>> I do not support adoption, because I believe the IETF should not
>>> standardize tools and techniques for decrypting TLS-protected data.
>>> It is harder for a TLS implementer to reject requests for IETF-blessed
>>> functionality.
>>>
>>> (As long as this remains on the Informational track, I believe it's
>>> somewhat less harmful.)
>>>
>>> Cheers,
>>>
>>> Andrei
>>>
>>> -----Original Message-----
>>> From: Sean Turner <[e-mail]>
>>> Sent: Thursday, July 25, 2024 9:16 AM
>>> To: TLS List <[e-mail]>
>>> Subject: [EXTERNAL] [TLS]Adoption call for SSLKEYLOG Extension file for
>>> ECH
>>>
>>> At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG
>>> Extension file for ECH I-D (
>>> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/)
>>> This message starts a two-weekl call for adoption. If you support adoption
>>> and are willing to review and contribute text, please send a message to the
>>> list. If you do not support adoption of this I-D, please send a message to
>>> the list and indicate why. This call will close on 8 August 2024.
>>>
>>> Thanks,
>>> Sean
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

 Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |  Cambridge,
MA