[ After this comment, stepping back for a while, I want to hear what others
think about the general shape of the alternative... ]
> On Dec 15, 2018, at 3:40 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie>
> wrote:
>
>> For opportunistic discovery, yes also DNS, but the DNS record would
>> just hold a stable indication of support for the protocol.
>
> Isn't the easiest attack on ESNI then to just block visibility
> of that boolean at which point a client will use SNI and not ESNI
> and it's game-over? That seems to imply the HRR scheme isn't
> any less dependent on DNS really, as I think ekr implied. (The
> HRR scheme could be much nicer in terms of operating DNS, but not
> more secure.)
The HRR scheme has better support for out-of-band local policy, that
resists the above attack, since the data that would be obtained via
DNS is comparatively stable, and could just be a local setting in
the user agent.
If one is willing to forgo authenticating the fronting server
(trade-off), the use of ESNI could simply be on by default,
discovered in-band by observing whether the server's HRR carries
an appropriate extension.
* Send sentinel client key_share that triggers HRR
* Omit all sensitive extensions.
* Send sentinel SNI
* Check server HRR for extension that indicates support
for encrypted extensions in client HELLO after HRR
* If present, encrypt all the client extensions including SNI.
* If absent, then proceed as before.
In this mode, there are no new DNS lookups, but we end up doing
an extra round-trip for all servers, even those that are not behind
CDNs and don't support the extension.
That is of course great news for not standing out of the crowd,
all traffic looks the same whether behind a fronting CDN or not,
*but* this forgoes the opportunity to learn (via a secure out
of band channel) the fronting server's name and authenticate it,
so the MiTM SNI disclosure attack is back.
We can trade-off broad deployment against active attack resistance,
but it seems difficult to have both. I'd be inclined to favour
broad deployment, and rely on Tor and the like (in combination
with ESNI) to make SNI disclosure through active attack less
useful to the attacker.
--
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
