Hiya, On 29/07/2019 01:32, Christian Huitema wrote: > > 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.
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. > 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. Sure, I know that and am fine with it being the default. > 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. If the public_name is censored, then there may be >1 solution needed, so allowing for more than one seems better than assuming there is one and only one solution in that circumstance. > > 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. That seems a bit like the HTTPSSRV proposal and maybe better in a different thread? S. > > -- Christian Huitema > > > >
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
