Moreover, substantively the same text has been in the document for years, and given that it's already been through both WGLC and IETF LC, I think it's really quite late to be relitigating it.
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07#section-12 -Ekr On Sat, Jun 14, 2025 at 6:44 PM Eric Rescorla <[email protected]> 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 > > -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]
