Re: [TLS] Encrypted SNI

Eric Rescorla <ekr@rtfm.com> Sun, 06 December 2015 04:32 UTC

Return-Path: <ekr@rtfm.com>
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 365381B30CE for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 20:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7OHc3aJtTFD for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 20:32:00 -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 13E5A1B30CD for <tls@ietf.org>; Sat, 5 Dec 2015 20:32:00 -0800 (PST)
Received: by ykdv3 with SMTP id v3so163436775ykd.0 for <tls@ietf.org>; Sat, 05 Dec 2015 20:31:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; 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=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 10.129.148.3 with SMTP id l3mr2929883ywg.155.1449376319389; Sat, 05 Dec 2015 20:31:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Sat, 5 Dec 2015 20:31:20 -0800 (PST)
In-Reply-To: <CA+cU71kgjRKAgbL2OdNAaB7QPhT0ZLHz=6EDDuQ5Vkd3xRGtBA@mail.gmail.com>
References: <CABcZeBPFAp4hD3ykY9pAA4=ELsAkNoa2yDhaoiSP917v5XgAiw@mail.gmail.com> <CA+cU71kqqTUnU7U-GN4s8a4YON27MEWxUN+CyiSCyUDpE+cgwA@mail.gmail.com> <CABcZeBNOBVwU4GU1HdJHdX1EhWqaS8UQ31D6ZqEoyWKfTb6Xkg@mail.gmail.com> <CA+cU71kgjRKAgbL2OdNAaB7QPhT0ZLHz=6EDDuQ5Vkd3xRGtBA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 5 Dec 2015 20:31:20 -0800
Message-ID: <CABcZeBPRUD8zQBBPaAaoHKwXxa=GaRg0Ao7Kw-4BfPhz4ekV3w@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: multipart/alternative; boundary=94eb2c07c8bca9ee6b052633384b
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CPKcWB6U5sKfiCKgt2oNnjHPF1Q>
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:32:02 -0000

On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter <tom@ritter.vg> wrote:

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

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


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:
http://www.ietf.org/mail-archive/web/tls/current/msg18118.html



> (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
long
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
hash.


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


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
ServerConfig
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.

-Ekr




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