Re: [TLS] Encrypted SNI

Tom Ritter <tom@ritter.vg> Sun, 06 December 2015 04:20 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C01B30A9 for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 20:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yusxAudjF5hK for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 20:20:25 -0800 (PST)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DD21B30A7 for <tls@ietf.org>; Sat, 5 Dec 2015 20:20:25 -0800 (PST)
Received: by ykfs79 with SMTP id s79so164361903ykf.1 for <tls@ietf.org>; Sat, 05 Dec 2015 20:20:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; 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; d=1e100.net; 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 10.13.194.193 with SMTP id e184mr16983422ywd.203.1449375624729; Sat, 05 Dec 2015 20:20:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.5.139 with HTTP; Sat, 5 Dec 2015 20:20:05 -0800 (PST)
In-Reply-To: <CABcZeBNOBVwU4GU1HdJHdX1EhWqaS8UQ31D6ZqEoyWKfTb6Xkg@mail.gmail.com>
References: <CABcZeBPFAp4hD3ykY9pAA4=ELsAkNoa2yDhaoiSP917v5XgAiw@mail.gmail.com> <CA+cU71kqqTUnU7U-GN4s8a4YON27MEWxUN+CyiSCyUDpE+cgwA@mail.gmail.com> <CABcZeBNOBVwU4GU1HdJHdX1EhWqaS8UQ31D6ZqEoyWKfTb6Xkg@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Sat, 5 Dec 2015 22:20:05 -0600
Message-ID: <CA+cU71kgjRKAgbL2OdNAaB7QPhT0ZLHz=6EDDuQ5Vkd3xRGtBA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ybiMgvysp9KBXOxnWXtP8yOGP5E>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypted SNI
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Dec 2015 04:20:30 -0000

On 5 December 2015 at 21:31, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter <tom@ritter.vg> wrote:
>>
>> On 5 December 2015 at 12:32, Eric Rescorla <ekr@rtfm.com> 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 example.com (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?

-tom

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