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, 5 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