Yeah, I think we will see more inadvertent logging than malicious, just as
we have seen passwords mistakenly deposited in logs for approximately as
long as we have had both logs and passwords.
One challenge with SSLKEYLOG is that there’s no way without very
system-specific inspection to detect whe
It doesn’t necessarily need to be malicious. With how much of software
deployment being massive YAML files with tons of environment variables,
mistakenly including this won’t be that difficult.
On Sun, Aug 4, 2024 at 07:00 Ilari Liusvaara
wrote:
> On Sat, Aug 03, 2024 at 02:38:29PM -0700, Christ
On Sat, Aug 03, 2024 at 02:38:29PM -0700, Christian Huitema wrote:
>
> The security considerations of
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ are pretty
> clear, but the discussion pointed out that environment variables can be
> installed without knowledge of most users. More
On 8/3/2024 11:03 AM, Eric Rescorla wrote:
...
The main SSLKEYLOGFILE document already contains the following
applicability statement [1], which also is referenced here in S 5:
The artifact that this document describes - if made available to
entities other than endpoints - complet
Hiya,
On 03/08/2024 19:03, Eric Rescorla wrote:
I'd like to make sure we're all on the same page about this draft.
The IESG has already approved the original TLS document on
SSLKEYLOGFILE [0], which contains the keying material necessary to
decrypt the connection. It's currently in the RFC Edit
opov
Sent: Donnerstag, 25. Juli 2024 18:30
To: Sean Turner ; TLS List
Subject: [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH
I do not support adoption, because I believe the IETF should not standardize
tools and techniques for decrypting TLS-protected data.
It is harder
Hi folks,
I'd like to make sure we're all on the same page about this draft.
The IESG has already approved the original TLS document on
SSLKEYLOGFILE [0], which contains the keying material necessary to
decrypt the connection. It's currently in the RFC Editor Queue.
The draft under discussion wou
I’m not a TLS insider but I’ve been watching this discussion, and…
On Aug 3, 2024 at 9:36:16 AM, hannes.tschofenig=40gmx@dmarc.ietf.org
wrote:
> Hence, this is not a mechanism that allows a third party in the middle of
> the network communication to somehow decrypt traffic. It is a tool for
,
sounds good to me though.
Ciao
Hannes
-Original Message-
From: Andrei Popov
Sent: Donnerstag, 25. Juli 2024 18:30
To: Sean Turner ; TLS List
Subject: [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH
I do not support adoption, because I believe the IETF should not
Hiya,
On 25/07/2024 17:30, Andrei Popov 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.
Same here.
(As long as
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
11 matches
Mail list logo
