Re: [TLS] Encrypted SNI

Eric Rescorla <> Sun, 06 December 2015 04:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 365381B30CE for <>; Sat, 5 Dec 2015 20:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7OHc3aJtTFD for <>; Sat, 5 Dec 2015 20:32:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13E5A1B30CD for <>; Sat, 5 Dec 2015 20:32:00 -0800 (PST)
Received: by ykdv3 with SMTP id v3so163436775ykd.0 for <>; Sat, 05 Dec 2015 20:31:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C6UpohFtDLfCPMsyzH4r2fYpceahGJ9D06VzAvl/ClE=; b=wtmia6+m1QJn1JLddFrc7DKwvJzXk9iXCvu605ZL+EKEOwqTVOpTU3RzKl8xB5441N 6uOTmzGUwWLYoifiOMBMmc9eZ3Oqc3F74rXhebGw724wRLq0Gl7KngOPyJCxMUHE0nOm SJaCVi6lx6r4Igs7mmE81g3hM3M4/iqCs3R5341fcbL1MlGe5MBNIMuy1+Xh+S9uRai/ Pt7bBAp96Cvx00GcuFrCKy6THtF6IUc8RpGLqsnaM/Q6cILVpWuYYIC6TGKQpXHlnjb1 pLTI9xaskuhn7Q9vtvIUfPLNcdS6ws/7YCwzRVpcdnHwDP8erjcjDJirv4gHJPxZR4r6 5aeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C6UpohFtDLfCPMsyzH4r2fYpceahGJ9D06VzAvl/ClE=; b=HGS/f6WG2qFKpLNVMmcpXLZwYc7iMknCXtV3XjoSjHYGgpilYdf9K5rQlRHPLJdAwj Kq88VpP7kW+OeFMvnSnMGTEw+9Kr/Ml7xczn+LHXpnjnEVRSgkHyKqw/QsDJmOu2Vwas XeG+bUlrvTACYriYScV35/shAFKQassZPfHdoQAjyc+zsHiRwlLrjOoTtcujxRNrkVyW kegofWxGU8hYh0kusw6ztSpSirLPyB3IoragSxPHuClKUAVqNmqPPI5WQQ6mhmNKMUuA PngIRaOqWpRTA3cyZOoDrZjBiwK4vQ/QCeOzKomZ9/XzDq0Fuu7WpT48n2DSwAZYGpuJ T0NQ==
X-Gm-Message-State: ALoCoQlyYpPPBOfW8XPY5BT780znOSFWgJEZ9RzLHWGxsUR2K4RDHL2fmUjK0OjT8sKWXwlhvPE/
X-Received: by with SMTP id l3mr2929883ywg.155.1449376319389; Sat, 05 Dec 2015 20:31:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Dec 2015 20:31:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Sat, 05 Dec 2015 20:31:20 -0800
Message-ID: <>
To: Tom Ritter <>
Content-Type: multipart/alternative; boundary="94eb2c07c8bca9ee6b052633384b"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Encrypted SNI
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Dec 2015 04:32:02 -0000

On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter <> wrote:

> On 5 December 2015 at 21:31, Eric Rescorla <> wrote:
> >
> >
> > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter <> wrote:
> >>
> >> On 5 December 2015 at 12:32, Eric Rescorla <> wrote:
> >> > Subject: SNI Encryption Part XLVIII
> >>
> >> A small concern that probably is "No, that can't happen", but I would
> >> want to be sure that a normal (non-encrypted SNI) ClientHello would be
> >> unable to be wrapped in a new ClientHello to a gateway by a MITM
> >> (without being detected.)
> >
> >
> > That would certainly be consistent with the proposed design. Why is that
> > bad?
> It doesn't seem safe that a MITM can actively change the way a
> handshake occurs and is processed by the other side without being
> detected. It's like asking for some sort of more complex attack. We
> don't allow a MITM to change other parts of the handshake.
> A trivial, though contrived, example could be a CDN that supports
> eSNI. All requests it receives from... Turkmenistan[0] use eSNI. Seems
> good? Actually the government blocks all client-originated eSNI
> requests and re-wraps them so to the outside world it appears less
> censored than it is. Could be done state-wide or (if god forbid we had
> a fallback) to individual clients.

Fair enough. This seems easily solved by requiring the internal
ClentHello to enclose a digest of the external ClientHello in some

Something analogous is not allowing an attacker to inject a
> HelloRetryRequest.We shouldn't allow that, either I think. I looked at
> #104 - it seems like the current plan _is_ to restart the handshake
> hash in the event of HelloRetryRequest but that a server cookie must
> be replayed?

No, that's not the current plan. See:

> (Theorizing the cookie is an HMAC containing the client
> ip and some other things?) I think there's an attack on that if an
> attacker can forge packets from a client. (HelloRetryRequest is not
> signed by the server, right?)
> Client supports SecureA, SecureB, and InsecureC. Server supports
> SecureA, SecureB, and InsecureC. Client sends a ClientHello with
> KeyShares for A & B. <Pause> Attacker forges a packet from the
> client's IP with support for C and RandomD and KeyShares for RandomD.
> Server replies with a HelloRetryRequest with a cookie for that client
> IP. Attacker forges a HelloRetryRequest from the server, copying the
> cookie, and saying "I only support InsecureC." <Unpause> The attacker
> sends the forged HelloRetryRequest to the client. Client makes a
> KeyShare for InsecureC and sends it along with the cookie, which the
> server recognizes as being from it for the IP, and everything proceeds
> using InsecureC undetectably.   I think.

Well the client sends shares for A, B, and C (it is required to append
the new share to the list, not replace it) for exactly this reason. So, as
as the server would prefer A or B given A, B, and C, you don't end
up with C. However, as I said, we are not planning to restart the handshake

>> Also, I'm a little confused about what the client is supposed to put
> >> in the outer SNI (for the gateway). Is this blank? Some constant?
> >
> > Whatever SNI you would use to talk to the gateway ordinarily. Otherwise
> > you would have a distinguisher.
> But... what is that?  If I look up (over my new private
> DNS link) and get an IP back to a CDN (which I wouldn't even know)...
> how would I know what the "normal gateway SNI" is?

Well, this isn't what would happen. You would get a response in something
other than an A record that contained "here is the DNS name of the gateway".
That's the only thing that can work because you need to solicit the
from the gateway in any case. I don't see how to make this work without
a channel richer than just an IP, since the client needs to know how to do
Encrypted SNI.


> -tom
> [0] To use a real-world example of a heavily censored national internet.