[TLS] Re: [EXTERNAL] 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

[Alicja Kario <[e-mail]>]

On Tuesday, 25 February 2025 18:47:33 CET, Andrei Popov wrote:
>   *   But I don't know of anywhere else with broad enough remit
>   *   to mandate a behavior for all applications using TLS.
> This is a common perception, and it is exactly why publishing 
> SSLKEYLOGFILE documents in the context of the IETF is a bad 
> idea. This creates additional pressure on other implementers to 
> support the backdoor.

Using charged language doesn't make it more true.
And this specification doesn't _mandata_ any kind of behaviour.
It only specifies that _if_ you support exporting key material, that's
_a_ way to do it.

>   *   So, while it is fine for some company's program to output 
> arbitrary debug files for their own development,
>   *   this wouldn't enable others to understand these files.
> There is nothing inherently wrong with the IETF standardizing 
> debugging interfaces and tracing/logging formats. My argument is 
> that protocol debugging is feasible without complete 
> compromise/exposure of the plaintext.

Sure! Any implementation can be ran under a debugger, with breakpoints set
that will automatically write the key data to file.

Should we mandate that cryptographic implementations should detect running
under a debugger and abort, because doing anything less "facilitates key
compromise"? No, that would be absurd.

>   *   For me this sounds more like,
>   *   "we know it's done, but we don't want to be aware of it"
> We know it's done, we know it's not secure, we know this 
> practice will continue with or without IETF standardization. It 
> does not follow that we should standardize existing insecure 
> practices.
> If the TLS WG is willing to work on TLS tracing/debugging 
> interfaces, the scope of the work should go beyond standardizing 
> an existing insecure practice.

It's not secure only in cases a system is already compromised.

All software cryptographic implementations have their keys in memory
in plaintext, it's only a question of how easy it is to get to them to
a text file.

> Cheers,
>
> Andrei
>
> From: Yaakov Stein <ystein=[e-mail]>
> Sent: Tuesday, February 25, 2025 4:53 AM
> To: [e-mail]
> Cc: Bellebaum, Thomas <[e-mail]>; 
> Aaron Zauner <azet=[e-mail]>
> Subject: [TLS] Re: [EXTERNAL] Re: 2nd Working Group Last Call 
> for The SSLKEYLOGFILE Formatfor TLS
>
> You don't often get email from 
> ystein=[e-mail]<mailto:ystein=[e-mail]>. 
> Learn why this is 
> important<https://aka.ms/LearnAboutSenderIdentification>
> All,
>
> I fully support standardizing the SSLKEYLOGFILE Format.
>
> While it is a debugging tool, that doesn't mean it doesn't have 
> to be standardized.
>
> Where I work we maintain a large set of protocol analysis tools
> used to verify correct operation of various programs, and 
> document variant behaviors.
> This often requires visibility into the internal operation of 
> various browsers and apps.
> So, while it is fine for some company's program to output 
> arbitrary debug files for their own development,
> this wouldn't enable others to understand these files.
>
> The documentation really doesn't have to be produced by the IETF,
> as long as everyone abides by it.
> But I don't know of anywhere else with broad enough remit
> to mandate a behavior for all applications using TLS.
>
> Y(J)S
>
> From: Aaron Zauner 
> <azet=[e-mail]<mailto:azet=[e-mail]>>
> Sent: Tuesday, February 25, 2025 12:27 AM
> To: Martin Thomson <[e-mail]<mailto:[e-mail]>>
> Cc: Bellebaum, Thomas 
> <[e-mail]<mailto:[e-mail]>>; 
> [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] [TLS] Re: 2nd Working Group Last Call for 
> The SSLKEYLOGFILE Formatfor TLS
>
> Hey,
>
> On Mon 24. Feb 2025 at 22:54, Martin Thomson 
> <[e-mail]<mailto:[e-mail]>> wrote:
> On Tue, Feb 25, 2025, at 06:56, Aaron Zauner wrote:
>> To be clear; I agree with that in principle but have the feeling that
>> the discussion around an applicable threat model misses the issue of
>> what should be in IETF and what should be in development docs,
>> debugging tools etc entirely. I'm not currently working on maintaining
>> a crypto lib as many of you are but you can't honestly tell me it's not
>> possible to work on your end without IETF guidance on debug specifics
>> that allow encrypted traffic detail export -- which you already have in
>> place for debug and dev anyway.
>
> This also misses the point.  The existence of this format (it 
> will exist whether the IETF publishes a document or not) has 
> enabled interoperation between a number of tools.  The point of 
> moving this work to the IETF was to transfer governance from 
> what was ad hoc to something recognized and respected by the 
> community of people who build the interoperating tools.
>
> Some people view interoperable standards as somehow changing 
> the demand and availability of the thing they document.  Maybe 
> that's true in some markets, but my experience is that the 
> demand is what causes the creation of standards, not the other 
> way around.  Also, if there were not already interoperation and 
> you were concerned that interoperation would cause problems, 
> this might be problematic, but this is a case where that 
> interoperation already exists
>
> I understand your point and just like config formats I see why 
> you'd want to have a published document. But just like with 
> configs it's part of the local tool chain and not a wire format. 
> Open source projects have been able to work with them and use 
> them without involving IETF. I'm just not sure this is the right 
> place for the document. You've done the work and documentation 
> anyway already, and you're interoperable. What do you really 
> gain by having this in IETF? It's also a fringe topic; With that 
> I mean in this case that it's debug specific to a few projects 
> related to TLS and while this is the TLS WG it's still a tooling 
> issue in my estimate. I'm really not sure what the big upside is 
> of having it published here. A lot of chrome, openssl and other 
> tool chain specifics are likewise only documented in the 
> relevant project documents and it works fine for everyone 
> involved; Is there any precedent that showed we need this in 
> IETF - ie. where interop and debugging didn't work out because 
> you couldn't already agree on a format and document it? Because 
> it seems to me the community has already achieved all of this 
> due to your and other people's contribution without adding it as 
> an IETF doc.
>
> Thanks,
> Aaron
>
>
>
> This message is intended only for the designated recipient(s). 
> It may contain confidential or proprietary information. If you 
> are not the designated recipient, you may not review, copy or 
> distribute this message. If you have mistakenly received this 
> message, please notify the sender by a reply e-mail and delete 
> this message. Thank you.
>
>

-- 
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic