Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

[Geoffrey Keating <[e-mail]>]

[e-mail] (Martin Rex) writes:

> If anyone really thinks that there should be a scheme where a
> server's hostname is no longer transfered in a cleartext (including
> TLS extension SNI), then first of all a *NEW* distinct URI method
> should be defined for that purpose, e.g. "httph://" as a reliable
> indicator to the client processing this URI, that the hostname from
> this URI is not supposed to be sent over the wire in the clear
> *anywhere*.

Although I can see how this, or some other mechanism, might be helpful,
I don't agree it has to happen *first*.  Why can we not start by providing
an ESNI mechanism, and then later standardize a mechanism to require it
for particular hostnames?

A limited-purpose client can just require TLS 1.3 and ESNI for all
connections, so such a mechanism would not be required for that
client.  In the future TLS 1.3 and ESNI deployment may be sufficiently
widespread that all clients could require them, making the mechanism
unnecessary.

Even if ESNI is opportunistic and so subject to active attacks, that
still eliminates passive network sniffing.  Even an active attack
would not (I think) lead to a successful connection, because of the
TLS anti-downgrade features, with consequences including user-visible
error messages or the device deciding the network is non-functional
and ceasing to use it, so although some hostnames may be revealed, the
user or device may stop before revealing all of them.  So ESNI is
still useful even if not mandatory.