On 15/06/2025 02:44, Eric Rescorla wrote:
This isn't an addition. This text was previously in an appendix and was just moved into the main text. Here is a direct link to this text in -24. https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.html#appendix-A
That's fair. And again, I'm not objecting. There's no process issue here. I'm just bemoaning;-) S.
-Ekr On Sat, Jun 14, 2025 at 6:11 PM Stephen Farrell <[email protected]> wrote:Hiya, I looked at the diff. I don't object to it, on the basis that getting an RFC out is better than faffing around for more years. I do think one of the changes is unwise, that being the addition of: ' Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. This is primarily because the outer ClientHello exists only in support of ECH. Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see Section 7). In contrast, the inner ClientHello is the true ClientHello used upon ECH negotiation." ' The above is logical in that it follows the logic the WG has accepted, but I've always thought ECHConfig extensions were a bad plan, so I'd be much happier with s/SHOULD/are expected to be/ in the above. I'd be even happier with s/SHOULD/might well be/ but am almost certainly in the rough on that. The 'why' of my position is that we have loads of TLS extension codepoints available, and if we need to change ECH that much we can more easily use something that is not 0xfe0d for extensibility. (And yes, I know others disagree with me on that.) Again though, it'll be better to emit an RFC than to spend yet more time on this, so I'm not objecting to -25, I'm only complaining:-) Cheers, S. On 14/06/2025 20:09, [email protected] wrote:Internet-Draft draft-ietf-tls-esni-25.txt is now available. It is a workitemof the Transport Layer Security (TLS) WG of the IETF. Title: TLS Encrypted Client Hello Authors: Eric Rescorla Kazuho Oku Nick Sullivan Christopher A. Wood Name: draft-ietf-tls-esni-25.txt Pages: 53 Dates: 2025-06-14 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-esni-25 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
