[TLS] Additional uses for SSLKEYLOGFILE entries

["Sipos, Brian J." <[e-mail]>]

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/