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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
