Thank you for writing the draft. I agree for the need to hide hostnames from passive attackers, and I really like the fact that the draft discusses of various attack vectors that a proper SNI protection should take care of.
OTOH, it makes me sad that the proposed methods require an additional roundtrip (when compared to no encrypted SNI). Can't we consider adopting a method that improves both performance and privacy, instead of choosing one between the two? Specifically, I wonder if we could consider embedding part of the TLS handshake within a secure DNS query / response. That will make the connection setup even faster than today at the same time providing us more privacy. Note that regardless of the approach, it is mandatory to migrate DNS onto a secure channel (i.e. over TLS or QUIC) in order to protect the hostname that the client is going to access. Protecting just the SNI is insufficient. Approach 1. embed TLS handshake in the DNS query and response A client queries a DNS over a secure channel. ClientHello is embedded to the DNS query. The resolver that receives the query will always contact the authoritative server by using a secure channel, transmitting both the DNS query and the ClientHello. Upon receiving the query, the authoritative server will send a DNS response that embeds the server's first flight of the TLS handshake (i.e. from ServerHello to ServerFinished). The resolver relays the DNS response (with the handshake messages) to the client. When the client receives the DNS response and the TLS handshake messages, it connects to the server (that is designated by the DNS response) and immediately sends the client's second flight of the TLS handshake (i.e. ClientFinished) with an identifier that correlates that message to the first flight of the messages transmitted through DNS, followed by application data. The merit of the approach is that connection setup will be even more faster than now, since the time being spent changes from 1 RTT-to-DNS + 1 RTT-to-origin to 1 RTT-to-origin-through-DNS (note that reducing the roundtrip to DNS has become important than before due to the fact that resolvers are less common to be located near the client. This is especially the case for mobile networks). Though there could be replay issues until the client receives the server's first flight through the direct connection. In short, the connection setup latency (including DNS) will be reduced from 2 RTT to 1 RTT, whereas in the approaches that are discussed in the draft it will change from 2 RTT to 3 RTT. Approach 2. embed TLS handshake originating from the server in DNS response This is a variation of the former approach. In this approach, a DNS query is sent over a secure channel but does not convey any TLS handshake massage. OTOH it is the server that initiates the handshake, upon receiving a DNS query. The DNS response (sent over a secure channel) will include the necessary parameters to establish an end-to-end secure channel (e.g. nonce, cryptographic parameters, server certificate, and a signature signing the values). When the client receives the DNS response that contains the handshake messages, it will use that to establish a secure connection to the server (by sending it's nonce and the negotiated parameters that are signed). The time required for establishing a connection will be the same as the first approach. However, one interesting difference from the former approach is that it will be possible for a DNS resolver to cache the DNS response including the server's first flight of the handshake messages (at the cost of losing single-op DH). Hence the change required to existing DNS infrastructure could be somewhat smaller. The risk would be that if the resolver reuses the DNS response, a passive observer could determine whether if multiple new connections went to the same origin (by looking at the identifier that designates the handshake that the client is responding to). If that is an issue, a client may want to inject randomness into the query to suppress the resolver from reusing the response. 2017-06-22 13:25 GMT+09:00 Christian Huitema <huit...@huitema.net>: > We has many discussions of SNI encryption on this list recently, and that > was enough motivation to write a draft about it. I am pretty sure that this > will be met with wide approval and no discussion at all :-). > > -- Christian Huitema > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-tls-sni- > encryption-00.txt > Date: Wed, 21 Jun 2017 21:17:26 -0700 > From: internet-dra...@ietf.org > To: Christian Huitema <huit...@huitema.net> <huit...@huitema.net>, Eric > Rescorla <e...@rtfm.com> <e...@rtfm.com> > > A new version of I-D, draft-huitema-tls-sni-encryption-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-tls-sni-encryption > Revision: 00 > Title: SNI Encryption in TLS Through Tunneling > Document date: 2017-06-20 > Group: Individual Submission > Pages: 19 > URL: > https://www.ietf.org/internet-drafts/draft-huitema-tls-sni-encryption-00.txt > Status: > https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ > Htmlized: > https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-huitema-tls-sni-encryption-00 > > > Abstract: > This draft describes the general problem of encryption of the Server > Name Identification (SNI) parameter. The proposed solutions hide a > Hidden Service behind a Fronting Service, only disclosing the SNI of > the Fronting Service to external observers. The draft starts by > listing known attacks against SNI encryption, and then presents two > potential solutions that might mitigate these attacks. The first > solution is based on TLS in TLS "quasi tunneling", and the second > solution is based on "combined tickets". These solutions only > require minimal extensions to the TLS protocol. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls