m...@sap.com (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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
