Re: [TLS] Encrypted SNI
Watson Ladd <watsonbladd@gmail.com> Sat, 05 December 2015 19:15 UTC
Return-Path: <watsonbladd@gmail.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 59DD81A878C for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 11:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, 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 1BOUOJQSvwfu for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 11:15:08 -0800 (PST)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 DEE201A0041 for <tls@ietf.org>; Sat, 5 Dec 2015 11:15:07 -0800 (PST)
Received: by ykdr82 with SMTP id r82so156671332ykd.3 for <tls@ietf.org>; Sat, 05 Dec 2015 11:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ubq83MINVUtks+BTChKLmoEflov6GXz9UesPYvyI57A=; b=aH/fNbEpDuEQCxMZ/lDHgk/UGcLcllRhoizUqrxvjbLbLav+LKRF7VX8BL/+U6M5+6 QhIsCmryIn8fVDI+c44k7E3EIqn4Ra8uRwMXpyfHrMa08A8EtrhJlzgwOZ/8Wh87/QNh ytLMtYdeKaZE4osBSt/ALyiK2SjZvxjPZMuq6skgCLxb59ahAaf7Zy7ha4Z1q/wyohxY SQvMm0oxG0Gsvv3Ua3iozBELLVep/8d+D3ZfzCla7UMS1/LqElxELXVTNIw58vpCgM0Y Any9ngjk2q64gkME+bV8mPwsVYXRdeRcfaGB0uRZEUtwudz99OJWHYHRC21qfnm8cpYB fLkw==
MIME-Version: 1.0
X-Received: by 10.129.57.135 with SMTP id g129mr15082394ywa.244.1449342907128; Sat, 05 Dec 2015 11:15:07 -0800 (PST)
Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 11:15:07 -0800 (PST)
In-Reply-To: <CABcZeBPFAp4hD3ykY9pAA4=ELsAkNoa2yDhaoiSP917v5XgAiw@mail.gmail.com>
References: <CABcZeBPFAp4hD3ykY9pAA4=ELsAkNoa2yDhaoiSP917v5XgAiw@mail.gmail.com>
Date: Sat, 05 Dec 2015 14:15:07 -0500
Message-ID: <CACsn0cnQTgdrazwn2dHWnZTKA4ASyr9ong1ZYfq2EoNvKQ-fdg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_xfCRa1idjgM0M0ChLQnJ25YQkc>
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: Sat, 05 Dec 2015 19:15:09 -0000
On Sat, Dec 5, 2015 at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension that indicates "tunnelled TLS" and (maybe) a new > TLS content type. We would only tunnel the first flight and everything > else would be handed off to the hidden service. This seems like the > minimal change to enable Encrypted SNI while retaining our existing > analytical frame for the rest of TLS. > > > DETAILS > During the discussion of SNI Encryption in Yokohama, Deb Cooley > argued that rather than messing with TLS to allow SNI encryption, > we should just tunnel TLS in TLS. A number of people objected > to this on the grounds of the performance cost for the gateway > because it has to encrypt and decrypt everything. > > After the meeting, Martin Thomson suggested a modification to the > tunnelling proposal that removes this cost. The key observation is > that if we think of the 0-RTT flight as a separate message attached to > the handshake, then we can tunnel a second first flight in it. Here's > the idea: > > Client Gateway Hidden > > ClientHello#1 > + KeyShare > + EarlyDataIndication > + SNI = gateway > (Finished) > ( > ClientHello#2 > + KeyShare > + SNI = hidden > <Finished> // > ) > (end_of_early_data alert) ----> > > ClientHello#2 > + KeyShare > + SNI = hidden > <Finished> ----> > ServerHello > + KeyShare > {EncryptedExtensions} > {ServerConfiguration*} > {Certificate*} > {CertificateRequest*} > {CertificateVerify*} > <------------------------------- {Finished} > {Finished} -------------------------------> > > > Key to brackets: > > () encrypted with Client->Gateway 0-RTT key (either handshake or data) > <> encrypted with Client->Hidden 0-RTT key > {} encrypted with Client->Hidden 1-RTT handshake > > > The way this works is that the Gateway decrypts the *data* in the > client's first flight, which is actually ClientHello#2 from the > client, containing the true SNI and then passes it on to the, Hidden > server. However, the Hidden server responds with its own ServerHello > which the Gateway just passes unchanged, because it's actually the > response to ClientHello#2 rather than to ClientHello#1. As long as > ClientHello#1 and ClientHello#2 are similar (e.g., differing only in > the client's actual share (though of course it must be in the same > group)), SNI, and maybe EarlyDataIndication), then an attacker should > not be able to distinguish these cases. > > > Notes on several obvious technical issues: > > 1. How does the Gateway distinguish this case from where the initial > flight is actual application data? See below for some thoughts > on this. > > 2. Can we make this work with 0-RTT data from the client to the Hidden > server? I believe the answer here is "yes", because the server's > EarlyDataIndication does not carry the configuration_id. I just > didn't show it in the diagram because it was already getting > complicated. > > 3. What happens if the Gateway server doesn't gateway, e.g., because > it has forgotten the ServerConfiguration? In that case, the > client gets a handshake with the Gateway, which it will have > to determine via trial decryption. At this point the Gateway > supplies a ServerConfiguration and the client can reconnect > as above. > > 4. What happens if the client does 0-RTT inside 0-RTT (as in #2 above) > and the Hidden server doesn't recognize the ServerConfiguration in > ClientHello#2? In this case, the client gets a 0-RTT rejection and > it needs to do trial decryption to know whether the rejection was > from the Gateway or the Hidden server. I've got another question: how does the client know that the gateway is supposed to be the gateway? As it stands it seems an attacker can MITM the Gateway, and recover all SNIs. Sincerely, Watson
- [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Watson Ladd
- Re: [TLS] Encrypted SNI Viktor Dukhovni
- Re: [TLS] Encrypted SNI Dave Garrett
- Re: [TLS] Encrypted SNI Salz, Rich
- Re: [TLS] Encrypted SNI Tom Ritter
- Re: [TLS] Encrypted SNI Tom Ritter
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Dave Garrett
- Re: [TLS] Encrypted SNI Jacob Appelbaum
- Re: [TLS] Encrypted SNI Salz, Rich
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Ilari Liusvaara
- Re: [TLS] Encrypted SNI Richard Barnes
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Ryan Sleevi
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Eric Rescorla
- Re: [TLS] Encrypted SNI Ilari Liusvaara
- Re: [TLS] Encrypted SNI Benjamin Kaduk
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Dave Garrett
- Re: [TLS] Encrypted SNI Toerless Eckert
- Re: [TLS] Encrypted SNI Eric Rescorla