On Sat, Dec 5, 2015 at 1:32 PM, Eric Rescorla <e...@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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
