Re: [TLS] ESNIKeys over complex

David Fifield <david@bamsoftware.com> Sat, 08 December 2018 18:45 UTC

Return-Path: <david@bamsoftware.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8BD130E4D for <tls@ietfa.amsl.com>; Sat, 8 Dec 2018 10:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bamsoftware.com
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 zJwTyTIYgPJH for <tls@ietfa.amsl.com>; Sat, 8 Dec 2018 10:45:11 -0800 (PST)
Received: from melchior.bamsoftware.com (melchior.bamsoftware.com [69.164.193.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEA5130E5F for <tls@ietf.org>; Sat, 8 Dec 2018 10:45:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bamsoftware.com; s=mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YnyAbYnrX40tpFY6VZjyifcyDdPm3i4KT3/YOXtCPJA=; b=oxn0XIpEtLBub0dNGoZ0UH7UTT Ev6+8TuyNjkC+CbcEIWh/D1TgZySuhUT9zTOwc20923viKRBUO3p1NpzNvcg1mLaAco+znakpHkuc fUvxUxkJRkHBqSqiq7GsA5k8lSFxBnpL3053Tdqic3ECJhgpKz2solPDIcA+oysDfVAA=;
Date: Sat, 8 Dec 2018 11:42:56 -0700
From: David Fifield <david@bamsoftware.com>
To: tls@ietf.org
Message-ID: <20181208184256.y55g7q2xdcuzv2c5@bamsoftware.com>
References: <797cd94d-b5be-24fd-923c-53b614cbc2c5@cs.tcd.ie> <20181208163830.GA7470@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20181208163830.GA7470@LK-Perkele-VII>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HXaV0macd6dRz0tYlpbtbfLxYUg>
Subject: Re: [TLS] ESNIKeys over complex
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Dec 2018 18:45:14 -0000

On Sat, Dec 08, 2018 at 06:38:30PM +0200, Ilari Liusvaara wrote:
> While thinking about the previous, I ran into some issues with the
> split mode. Firstly, if the fronting server does not encrypt the
> client_hello when transmitting it to backend server, passive attack
> can match incoming connections with backend servers. This reduces
> anonymity set to a single backend server (a lot smaller set).
> 
> And secondly, even if server encrypts the client_hello, but does not
> use a tunnel to backend, if server does not have client hello replay
> filtering (and such filtering is hard on typical fronting servers),
> replay attacks and some very simple traffic analysis can discover the
> backend server (again reducing the anonymity set by a lot).
> 
> This means that the fronting server should have an encrypted tunnel
> with the backend server (and there is likely double encryption).

I see--you're thinking of an observer who can see "both sides" of a
connection: the link between the Client and the Client-Facing Server,
and the link between the Client-Facing Server and the Backend Server.
I agree: such an observer could, through timing analysis, deanonymize
client connections (i.e., tell which Backend Server the Client is
accessing, as if it were accessing directly and not through the
Client-Facing Server). I suppose to really defend against a global
observer, you would need some kind of mixnet.

It looks like a little bug in the draft. I've checked just now and I
don't see that it says exactly *where* the observer is. I had assumed
that the observer only sees the Client–Server link (in Shared Mode) or
the link between Client and Client-Facing Server (in Split Mode).

I don't understand your point about replay and encrypting the Client
Hello. An observer doesn't need to see the contents of the Client Hello
to identify a Backend Server--the destination IP address is enough. I
don't see what specific attack you have in mind using replay, but it
seems to me that even an encrypted tunnel is insufficient. Unless the
encrypted tunnel additionally obfuscates packet sizes and timing, an
observer can correlate e.g. burst sizes and match incoming flows to
outgoing flows, in the manner of website fingerprinting.