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 debugging, and it is understood that
certain SW vendors want to agre
I support publication.
On Wed, Feb 19, 2025 at 10:06 AM Salz, Rich wrote:
> No issues with publication nor with the content.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
_
I also agree. I understand that according to the draft, the SSL backdoor
feature should only be present in debugging builds, but I am concerned
there will be a big pressure to have it enabled in production builds as
well. Consider the support line call, "I cannot access
https://example.com/";.
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 hardware, sure
you need to trust it in any case. If it is some parts of so
> I disagree with this because if an attacker could write to the environment
> variable used by the program or is able to side-load a library and capture
> outbound packets, it is very likely that they already have privileged
> access to the machine.
I am questioning the threat model. Just like Pe
Dear Sean Turner,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
tls Session 1 (1:00 requested)
Tuesday, 18 March 2025, Session III 1530-1630 Asia/Bangkok
Room Name: Sala Thai Ballroom [Breakou
On 21/02/2025 23:44, Martin Thomson wrote:
I realize that this won't change your mind Stephen, but...
Indeed, it doesn't change my view.
But it is an improvement, so thanks,
S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS
I realize that this won't change your mind Stephen, but...
On Sun, Feb 9, 2025, at 10:12, Stephen Farrell wrote:
> Less importantly, but still substantively, the draft does not,
> but should, recommend that this feature only be available via
> conditional compilation (where available) and not be p
