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=40allot....@dmarc.ietf.org>
Sent: Tuesday, February 25, 2025 4:53 AM
To: tls@ietf.org
Cc: Bellebaum, Thomas <thomas.belleb...@aisec.fraunhofer.de>;
Aaron Zauner <azet=40azet....@dmarc.ietf.org>
Subject: [TLS] Re: [EXTERNAL] Re: 2nd Working Group Last Call
for The SSLKEYLOGFILE Formatfor TLS
You don't often get email from
ystein=40allot....@dmarc.ietf.org<mailto:ystein=40allot....@dmarc.ietf.org>.
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=40azet....@dmarc.ietf.org<mailto:azet=40azet....@dmarc.ietf.org>>
Sent: Tuesday, February 25, 2025 12:27 AM
To: Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>>
Cc: Bellebaum, Thomas
<thomas.belleb...@aisec.fraunhofer.de<mailto:thomas.belleb...@aisec.fraunhofer.de>>;
tls@ietf.org<mailto:tls@ietf.org>
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
<m...@lowentropy.net<mailto:m...@lowentropy.net>> 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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
