Hello Watson, On Sat, Nov 16, 2024 at 1:47 AM Watson Ladd <watsonbl...@gmail.com> wrote:
> 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. > Yes, that would be great but that draft is already way past WGLC to make such a change. > 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). > Good point. For simplicity and ease or read labels introduced by this draft should be added to the "Table 1". > > 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. > The problem with outer for all cases is that it would require significant change to TLS libraries - they would need to keep in memory random from both inner and outer ClientHellos if SSLKEYLOGFILE enabled. This is a significant change in logic that might defeat the purpose of SSLKEYLOGFILE as a troubleshooting feature. Today TLS libraries that support ECH tend to discard random from outer ClientHello once ECH got negotiated. Wireshark performs the same thing as a client would to figure out if ECH was accepted or not - computes transcript with decrypted and "re-inflated" ClinetHello and compares bytes of ServerHello random (taking into account potential HRR shenanigans). It then uses random from corresponding ClientHello - inner if computation matched or outer if it did not. The presence of ECH_SECRET and ECH_CONFIG on their own does not imply that ECH was successfully accepted - especially if SSLKEYLOGFILE is generated by the client side. > > I hope these comments are useful. > Absolutely! Thank you for constructive comments. > > Sincerely, > Watson Ladd > Best Regards, Yaroslav > > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
