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
