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 -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 work > item > > of 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
