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

2025-02-24 Thread Aaron Zauner
Hi, On Mon 24. Feb 2025 at 13:02, Achim Kraus wrote: > Hi List, > > In my experience, this is mainly use to feed the "TlsKeyLog" from some > application into wireshark. And it's curious to me, that not having a > specified format within the IETF/TLS will provide any security. > > For me this sou

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

2025-02-24 Thread Martin Thomson
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

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

2025-02-24 Thread Aaron Zauner
Hi, On Mon 24. Feb 2025 at 14:57, Alicja Kario wrote: > On Friday, 21 February 2025 22:15:06 CET, Muhammad Usama Sardar wrote: > > On 20.02.25 13:36, Alicja Kario wrote: > > > >> if you can't trust the system you're running an application on, you > >> *definitely* can't trust any network connect

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

2025-02-24 Thread Aaron Zauner
Hey, On Mon 24. Feb 2025 at 22:54, Martin Thomson 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 sh

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

2025-02-24 Thread Arnaud Taddei
Sorry to be extensively late on the overall TLS mailing list (1), on this one Debugging and security need some level of visibility and they can't operate in the dark. The battle for a 'some of us need a respectful inspection full model precisely because there is one inspection that *wants* to be

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

2025-02-24 Thread Achim Kraus
Hi List, In my experience, this is mainly use to feed the "TlsKeyLog" from some application into wireshark. And it's curious to me, that not having a specified format within the IETF/TLS will provide any security. For me this sounds more like, "we know it's done, but we don't want to be aware o

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

2025-02-24 Thread Bellebaum, Thomas
> Some things should not be standardized. The problem is that there is a longing for such standardization. And not just at the IETF. The idea of the draft is, after all, to republish a "de facto standard" already implemented by many applications and debugging helpers alike. Someone had the need

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

2025-02-24 Thread Alicja Kario
On Friday, 21 February 2025 15:43:32 CET, Andrei Popov wrote: I agree with Stephen and Tomas on this one. Additionally, in my opinion, this WG should not have published any SSLKEYLOGFILE documents, because they effectively standardize a backdoor. It is understood that there is a need for debugg

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

2025-02-24 Thread Alicja Kario
On Friday, 21 February 2025 22:15:06 CET, Muhammad Usama Sardar wrote: On 20.02.25 13:36, Alicja Kario wrote: if you can't trust the system you're running an application on, you *definitely* can't trust any network connections from it It depends on how you define "system" here. If it is the ha