On 7/28/2019 5:25 AM, Stephen Farrell wrote: > 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.
I see the intent, but I am not sure it is practical. A lot of the HTTP connection establishment is automated. Given a server name, the client will do a lookup for the ESNI record or a cached value. If there is one, the simple solution is to put the public name in the SNI extension and the actual name in the ESNI extension. If the public name is censored, the solution is probably to look for a different ESNI record for the server, one that would mention a different public name. By the way, I think that the current ESNI record is maybe a little too complicated. The ESNI key is really a property of the public server, yet the ESNI record is defined as a property of the hidden server. If the public server rolls a new key, all the ESNI records of all the hidden servers that mentioned the old key need to be updated. I think it would be simpler to have the ESNI record as a property of the public server, and to just have a pointer to the public server in the context of the hidden server. May an SRV record. The chain would be something like: 1) Look up whether the SRV record for _esni._tcp.hidden.example.com 2) If there are such records, select the appropriate public server, say public.example.net 3) Look up ESNI, A, AAAA for public.example.net In that architecture, there is no need to encode the public server name in the ESNI record. I think there will be several advantages. The ESNI record's TTL can be set to the lifetime of the key. The SRV record's TTL can be set to the expected lifetime of the relation between 'hidden" and "public". If the SRV lifetime is long enough, the value can be efficiently cached by the client. If multiple clients share the same hidden server, the ESNI record is fetched only once, and can be cached. At connection time, the client would only need to query the A/AAAA records of the public server, i.e. exactly the same DNS transaction as an access to the public server. -- Christian Huitema
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
