Hiya, On 29/07/2019 14:35, Ben Schwartz wrote: >> In which case I must've explained it badly, because it's >> entirely practical:-) Let me try again... >> >> What I'm asking is that we not insist that the cleartext >> SNI is the ESNIKeys.public_name even though those will be >> the same value in almost all cases. >> >> I don't think there's any major security benefit to insisting >> that they be the same and there are cases where e.g. a command >> line tool like curl or wget can easily supply a different >> cleartext SNI value as an override, should that ever be needed >> or useful. >> > It sounds like you are arguing for replacing a MUST with a SHOULD.
Sure, that'd be good enough, though I think a MAY is actually all that's needed. I think the way I'd phrase it might be "clients are advised to include the value of ESNIKeys.public_name in the TLS handshake in the cleartext SNI extension; servers need to be aware that some clients might not do so, either omitting cleartext SNI entirely or including some other value that may or may not be meaningful at that server; successful ESNI decryption means ignoring any cleartext SNI value provided" and avoid use of 2119 terminology, but I'm sure various possible wordings would be fine. > I think our best option is probably to clarify who is supposed to do what, > and why. For example, we could say that a compliant client MUST set sni = > public_name so that fallback can work on servers with multiple public > names, I'm pretty sure I disagree with the above MUST as being necessary. But what do you mean by "so that fallback can work"? ISTM that if ESNI doesn't work, then the right thing is for the server to fail or continue the TLS h/s based on the cleartext SNI as normal, or to default to something if no cleartext SNI is provided, again as normal. A client that's not only greasing MUST of course make it appear to the client application that the TLS h/s failed, as ESNI has failed. > but the server MAY accept connections with missing or unrecognized > SNI to enable connections from non-compliant clients that prefer not to > include the public_name. Right. I'd expect some variation in all this and would like that we can make ESNI work even for clients with somewhat outdated or incorrect information, if there's no security downside in so doing. Cheers, S. >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
