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. The file should have some info on which protocol it contains keys for. John Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Sipos, Brian J. <brian.si...@jhuapl.edu> Sent: Thursday, February 27, 2025 3:12 PM To: tls@ietf.org <tls@ietf.org> Subject: [TLS] Additional uses for SSLKEYLOGFILE entries 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
