I was remiss in not closing this out. More discussion has gone over here:
https://mailarchive.ietf.org/arch/msg/tls/GXE38LHQVJk219HPq5goi_HO81M/
spt
> On Feb 7, 2025, at 10:52 AM, Sean Turner wrote:
>
> This email starts the 2nd working group last call for "The SSLKEYLOGFILE
> Format for TLS”
Fascinating thread.
I propose *NoSecurity* mode. Debug mode, with an insecurity label.
Perhaps defining SSLKEYLOGFILE only in debug mode is tolerable.
On Thu, 20 Feb 2025, 11:28 Ben Smyth, wrote:
> On Thu, 20 Feb 2025 at 10:13, Bellebaum, Thomas <
> thomas.belleb...@aisec.fraunhofer.de> wrote:
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
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
>
_
Standard file formats seem fine, non?
On Thu, 20 Feb 2025, 21:20 _ _, wrote:
> Hey,
>
> 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
Hey,
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.
However, I acknowledge that allowing an attacker
> I think we should abandon this effort and not publish.
>
> When initially proposed this was supposed to be documenting a
> deployed reality. I could just about hold my nose with that,
> but adding in ECH (for which key exfiltration is not currently
> deployed, nor seemingly needed) and the IANA
> The connection is secure. TLS doesn't defend against compromised devices.
I disagree. While the *network* connection itself may inhibit the rather
technical notions of confidentiality and integrity, this is not what the
average user would consider a "secure connection". Staying with a browser
On Thu, 20 Feb 2025 at 10:13, Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> > A TLS application interacting with an end-user (e.g. a browser) MUST
> clearly communicate any requests to log TLS secrets to the user and MUST
> NOT indicate a secure connection.
>
The connection i
Hello,
I have just become aware of this draft and I believe there might be a good
cautionary addition I would like to propose:
Specifically, I am worried that with further encouragement to standardize this
format, it will become a convenient way to surveil unsuspecting end users. All
this requ
No issues with publication nor with the content.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Just a reminder that this call is still on going.
spt
> On Feb 7, 2025, at 10:52 AM, Sean Turner wrote:
>
> This email starts the 2nd working group last call for "The SSLKEYLOGFILE
> Format for TLS” I-D, located here:
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
>
> The WG
I think we should abandon this effort and not publish.
When initially proposed this was supposed to be documenting a
deployed reality. I could just about hold my nose with that,
but adding in ECH (for which key exfiltration is not currently
deployed, nor seemingly needed) and the IANA considerat
I think the answer is clear: No, we should not accept both labels. We should
simply fix it to say EARLY_EXPORTER_SECRET and move on.
That’s fine with me. I was honestly just asking.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to t
Uploaded https://github.com/tlswg/sslkeylogfile/pull/22 to fix the typo.
On Fri, Feb 7, 2025 at 1:56 PM David Benjamin wrote:
> On Fri, Feb 7, 2025 at 1:55 PM David Benjamin
> wrote:
>
>> Accepting both labels gets super messy because then we have to make a
>> bunch of decisions like whether yo
On Fri, Feb 7, 2025 at 1:55 PM David Benjamin wrote:
> Accepting both labels gets super messy because then we have to make a
> bunch of decisions like whether you output both labels on the logging side.
>
> But we can just do a bit of research here:
> - In IETF land, EARLY_EXPORTER_MASTER_SECRET
Accepting both labels gets super messy because then we have to make a bunch
of decisions like whether you output both labels on the logging side.
But we can just do a bit of research here:
- In IETF land, EARLY_EXPORTER_MASTER_SECRET dates to the start of the I-D,
but...
- The shorter EXPORTER_SEC
The question is really "should we accept both names?"
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Changing it would be incompatible, but at a glance it looks like
EARLY_EXPORTER_MASTER_SECRET is the only label that would be impacted? We
definitely should not rename that to ...MAIN... because that's not the new
name. It's simply EARLY_EXPORTER_SECRET.
As for the right name, maybe we can still r
I read the draft. Looks good. Nice to see the word "octothorpe" instead of
pound sign, even if the document left of the last letter "e"
More seriously, should the draft allow the "new" terminology proposed in
8446bis (e.g., MAIN instead of MASTER etc)?
___
21 matches
Mail list logo
