A few things jumped out about IANA registries. The first is a silly process question that might be really ugly to address now (and require the IESG)
Shouldn't the IANA registry here be made by the draft-ietf-tls-keylogfile? That would make more sense. And we don't seem to tell IANA to add the new labels defined here. To my mind that needs to happen lest IANA not notice they were supposed to do something we didn't explicitly say in the right format (deservedly so! We should be really explicit to make their lives and ours easy). Substantive issues: Section 4 I don't think is right. I think we want outer in all cases because that's easier, There's lots of reasons a negotiation might fail, and the interpreter of the data might not see this. In fact, how does e.g. Wireshark know what matches the pcap if we use the InnerClientHello random? I can see a process logging also logging the secrets before knowing if success happened. I hope these comments are useful. Sincerely, Watson Ladd On Fri, Nov 15, 2024 at 4:18 PM Joseph Salowey <j...@salowey.net> wrote: > > This is the working group last call for SSLKEYLOGFILE Extension for Encrypted > Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1] and reply to > this thread indicating if you think it is ready for publication or not. If > you do not think it is ready please indicate why. This call will end on > November 30, 2024. > > Thanks, > > Joe > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-ech-keylogfile/ > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
