[Lake] Re: EDHOC live debugging

[John Mattsson <[e-mail]>]

Hi Brian,

I think EDHOC parameters should not be mixed with TLS parameters in the same registry. As TLS is planning to have the registry in the TLS IANA name space, I think the easiest way forward is to write a lake draft that suggests to create a new registry under https://www.iana.org/assignments/edhoc/edhoc.xhtml and registers the needed parameters there.

John

From: Brian Sipos <[e-mail]>
Date: Friday, 28 February 2025 at 18:43
To: John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Lake] EDHOC live debugging
John,
That is a good point, thank you. I've done a little prototyping on this and will have some detail to present at IETF 122 if my time slot is approved. I've also sent out some questions to TLS WG about potential use of the SSLKEYLOGFILE format and/or label registry for EDHOC secrets.

Brian S.

On Thu, Feb 20, 2025 at 10:36 AM John Mattsson <[e-mail]<mailto:[e-mail]>> wrote:
Hi Brian,

>EDHOC already includes a C_I which can be assumed unique under specific conditions as an analog to the keylog >"client_random" correlator.

The analog to 'client_random' would be G_X. C_I would be a bad choice for this, as the client can reuse it as soon as the old connection is no longer needed.
John

From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 20 February 2025 at 16:19
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Lake] EDHOC live debugging
WG,
Is there any general interest to enable the same type of live or offline traffic inspection and protocol debugging for EDHOC as currently enabled with TLS and DTLS using the SSLKEYLOGFILE secret storage technique [1]? EDHOC already includes a C_I which can be assumed unique under specific conditions as an analog to the keylog "client_random" correlator.

The internal key schedule for EDHOC is more complex than [D]TLS, but some simplifying assumptions about which messages are available to decode would narrow down the minimum need for EDHOC shared secrets. I think using a file-based input to diagnostic tools is more hands-off and automate-able than using manual export/entry of secret fields such as what is used for IKEv2 in Wireshark [2].

Any thoughts on or support of this idea?
Brian S.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
[2] https://www.wireshark.org/docs/wsug_html_chunked/ChIKEv2DecryptionSection.html