Re: [TLS] Encrypted SNI

Tom Ritter <> Sun, 06 December 2015 04:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A0C01B30A9 for <>; Sat, 5 Dec 2015 20:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yusxAudjF5hK for <>; Sat, 5 Dec 2015 20:20:25 -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 65DD21B30A7 for <>; Sat, 5 Dec 2015 20:20:25 -0800 (PST)
Received: by ykfs79 with SMTP id s79so164361903ykf.1 for <>; Sat, 05 Dec 2015 20:20:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mQlHFZXPfX+lArognhzj5ZYqezdQhYCfRkQg5IZcCFA=; b=NOas0AUWKt25GxcP7gKvUabCV9/eK/KDC4zCwazUljMbWF6yHVbT9MxfGWfnb6jQgu cpiQf9sJi4A5WaSDmBnZR1018XU0WH+TXU8jjmkUKiXS0XENiWMNFKuHf7J9ozrGpPfK CPEmOGHtwEOjofycnXelvivkibpk5rbDE2pZE=
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=mQlHFZXPfX+lArognhzj5ZYqezdQhYCfRkQg5IZcCFA=; b=Iu3tBVIQv4jf7ofIW9ptAo0G7wQ2YO/BCD2RKuRyofJAwdDSri1/zFbG2+ID30nX9V 3TnUP9x/0s0k57ucdYwr2nyNrP8GhY9hkBmgQzGqyByVRPdEodu5lrYETcuvA2B3AaKn ciwi8evkgzzdk58n+lcKJC+yx3wNd5J63Kgpnbt68d9Ke9Z4rkHexoBXvEP4WuHmkUfL Qm3bXruVclkx+sX6d2FQdO2RiXBLkl67S4YguTnPI80khDY9rsMRji4A1vnqZCxQKc00 u7Y8WUM/JkORcZhxd3hXBZQPlG/gN1mGHLNDqZ1B1Frs8ISA9dzqtOR+VvnWsk9GLuBJ OkuA==
X-Gm-Message-State: ALoCoQkkEKqPPiCb0tqtAdgCXlDw6W6QUoFf5nQSDR5FPlNNVcschCWTT6C/BppignaDovnzucgr
X-Received: by with SMTP id e184mr16983422ywd.203.1449375624729; Sat, 05 Dec 2015 20:20:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Dec 2015 20:20:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Tom Ritter <>
Date: Sat, 05 Dec 2015 22:20:05 -0600
Message-ID: <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
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:20:30 -0000

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.

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? (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.

>> 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?


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