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 encapsulated in TLS. Best Regards, Yaroslav On Fri, Feb 28, 2025 at 4:05 PM Eric Rescorla <e...@rtfm.com> wrote: > 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 that this is otherwise a good idea and there is consensus, > etc.) then they should publish their own specifications with their own > keywords, even if those just point to this document for the actual details. > > -Ekr > > > On Thu, Feb 27, 2025 at 6:13 AM Sipos, Brian J. <brian.si...@jhuapl.edu> > wrote: > >> TLS WG, >> >> I’ve been looking into a mechanism to inspect and diagnose behaviors of >> the EDHOC protocol (RFC 9528) in a way that doesn’t require >> human-in-the-loop between the entities-under-test and the diagnostic tools >> (e.g. live Wireshark capture). The existing TLS/DTLS dissectors make use of >> the almost-standard [1] SSLKEYLOGFILE mechanism and I think this is a good >> path for EDHOC use without needing to reinvent concepts and workflows. >> >> >> >> Is there any fundamental objection to eventually allocating labels >> specifically for EDHOC use? For non-EDHOC-aware users these would just >> function as reserved names which are ignored for TLS/DTLS uses. >> >> >> >> Otherwise, the EDHOC derived secrets listed in [2] are the basis from >> which some could be included in a keylog file. There was some mailing list >> discussion [3] about reviewer recommendations for not including secrets >> from which others can be directly derived. To me this would steer the EDHOC >> use to include PRK_2e, TH_2, K_3, IV_3, K_4, IV_4, and PRK_exporter but >> these details can be discussed in the LAKE WG. >> >> >> >> Thanks for feedback, >> >> Brian S. >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ >> >> [2] https://www.rfc-editor.org/rfc/rfc9528.html#figure-6 >> >> [3] >> https://mailarchive.ietf.org/arch/msg/tls/VCCmjU6py0-nbf7fJf0kUK4SPDk/ >> >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
