Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Kazuho Oku <[e-mail]>]

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 <[e-mail]>:

> 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: [e-mail]
> To: Christian Huitema <[e-mail]> <[e-mail]>, Eric
> Rescorla <[e-mail]> <[e-mail]>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
Kazuho Oku