Hiya, ESNI drafts -03 and -04 envisage that the ESNIKeys.public_name and the TLS h/s cleartext SNI are the same. I'd expect that they mostly will be.
But they don't have to be. A client could provide a way to use a client-chosen cleartext SNI when using ESNI to encrypt the real SNI. For example, my openssl build allows this for s_client. I've a colleague who's got a first build of curl using that that also allows such a local over-ride. I think other command-line clients might be likely to also support that kind of thing, if for no other reason than the existence of the draft-02 version that's deployed and has no public_name. But I guess being able to do a local over-ride may also be generally useful, while not being so useful for web browsers. For example, if a given public_name value is being censored, clients might at that point want to use something else. On the server side, my code also make no checks that the cleartext SNI used was the same as the public_name. And I don't think that causes any problems, so maybe ought be allowed too. I don't think allowing this (if the WG decide to) requires any major change to the spec, but there are a couple of language changes needed in section 5.1.3 and I guess we should add a sentence to the effect that using the public_name value from ESNIKeys in the cleartext SNI is recommended if you've no other value but is not required. 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
