I fully agree.
A common property of all the entries in the current format is Random from
TLS ClientHello as the session key. I think it would be great to keep it
that way.
That is, I believe that new labels should only be used for potential future
TLS extensions and protocols that are always enca
Hi Ilari,
At 12:18 AM 28-02-2025, Ilari Liusvaara wrote:
What kind of private keys? Is that just the known trouble (TLS_RSA_*,
TLS_PSK_* and the session ticket extension), or is it also other key
types? Of those, only the pure-PSK stuff remains in TLS 1.3 (TLS 1.3
does have session tickets, but t
Without weighing in on the rest of this debate, I don't think that
"SSLKEYLOGFILE" and it's associated registry should become a generic
carrier for keying material for other protocols. It's not like this is a
complicated format. If those protocols wish to define some expert (assuming
ad arguendo th
> Step0: we have this existing deployed thing we want to document.
As I wrote in [1], republishing without adding considerations and guard rails
is already bad.
> I think it is an interesting idea to use the KEYLOG format to help
> debugging of other security protocols. I think easy debugging he
On 28/02/2025 10:47, John Mattsson wrote:
I think it is an interesting idea to use the KEYLOG format to help
debugging of other security protocols. I think easy debugging helps
deployment of security protocols.
I think each protocol should have its own registry. The registries
could be listed
I think it is an interesting idea to use the KEYLOG format to help debugging of
other security protocols. I think easy debugging helps deployment of security
protocols.
I think each protocol should have its own registry. The registries could be
listed under the same IANS KEYLOGFILE name space.
keys are only used once) are ephemeral, I don’t
think the symmetric keys in TLS can be described as ephemeral.
John
From: Ilari Liusvaara
Date: Friday, 28 February 2025 at 09:20
To: TLS@ietf.org
Subject: [TLS] Re: Additional uses for SSLKEYLOGFILE entries
On Thu, Feb 27, 2025 at 12:59:56PM -0800
On Thu, Feb 27, 2025 at 12:59:56PM -0800, S Moonesamy wrote:
> Hi Brian, Stephen,
> At 06:18 AM 27-02-2025, Stephen Farrell wrote:
> > From my POV yes: fundamentally it is a bad idea for
> > the IETF to standardise ways to exfiltrate keys
> > even if there may be innocuous uses for those. And
> > t
Hi Brian, Stephen,
At 06:18 AM 27-02-2025, Stephen Farrell wrote:
From my POV yes: fundamentally it is a bad idea for
the IETF to standardise ways to exfiltrate keys
even if there may be innocuous uses for those. And
this latest ask (extending the exfiltration from
being a TLS-only thing, to cove
Hiya,
On 27/02/2025 14:10, Sipos, Brian J. wrote:
Is there any fundamental objection to eventually allocating labels
specifically for EDHOC use?
From my POV yes: fundamentally it is a bad idea for
the IETF to standardise ways to exfiltrate keys
even if there may be innocuous uses for those.
10 matches
Mail list logo
