Re: [TLS] ESNI padding the Certificate message

David Fifield <david@bamsoftware.com> Thu, 13 December 2018 17:38 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 36DAB130E03 for <tls@ietfa.amsl.com>; Thu, 13 Dec 2018 09:38:56 -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 z2uEWQhrV_Zy for <tls@ietfa.amsl.com>; Thu, 13 Dec 2018 09:38:54 -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 DDE64130DFA for <tls@ietf.org>; Thu, 13 Dec 2018 09:38:53 -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=1Pvle3m7/DZfYJAosakqbz7qQBWJWlibQO/H9owytJg=; b=BTZ0q5Qt6mnR2FNb+BbuP9vpkQ pNBrU8RB7urIR2TKsjEgjifyKu8DdIwUAGZG1N8cMB611pXltgBn1s9y46Guxn5PxrlS6OFqjqswA HJtPov3Q46yFEv2BNxrn1OG325B5SqQ/etC8yRCs/lrp9H+Ic4Mo6TFTbsRjNhfc6emU=;
Date: Thu, 13 Dec 2018 10:36:39 -0700
From: David Fifield <david@bamsoftware.com>
To: tls@ietf.org
Message-ID: <20181213173639.2deiqelrfjkkrfw2@bamsoftware.com>
References: <876187a2-df66-2eb0-5a55-b6e67cf668f6@cs.tcd.ie> <B3D20A93-3332-4541-8108-E4EFB08FBF6F@dukhovni.org> <CABcZeBM+ekw7xSzbz6Kh4aRbWXpy5f1U-iUu8W1fDKjVuUJ+3A@mail.gmail.com> <20181213160254.GJ79754@straasha.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20181213160254.GJ79754@straasha.imrryr.org>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/efOXoedveUsTbkw2h3WRT6SmkPo>
Subject: Re: [TLS] ESNI padding the Certificate message
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: Thu, 13 Dec 2018 17:38:56 -0000

On Thu, Dec 13, 2018 at 11:02:54AM -0500, Viktor Dukhovni wrote:
> On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote:
> 
> > Random padding does poorly with repeated trials. So, for instance,
> > if I get to observe a large number of requests from the same client
> > to the same server, you can gradually infer the length of the cert
> > chain.
> 
> Yes, I was aware of this.  But one might also note that may services
> are not behind a CDN, and that data traffic patterns after the
> handshake can also fingerprint the target service.
> 
> Session resumption helps to reduce the number of full handshakes
> that leak some information about the certificate size.
> 
> Users who really want (better) protection against traffic analysis
> should use Tor.  TLS traffic analysis protection from ESNI et. al.
> is IMHO best-effort protection for casual use.
>
> If a user visits just one site (and no others) at a particular CDN,
> absent traffic flow obfuscation ala Tor, the user's TLS traffic
> will eventually stand out from the noise.

Tor does not really offer protection against traffic analysis, apart
from hiding the source and destination IP addresses. In fact a lot of
website fingerprinting research uses Tor as a carrier, *because* it
preserves features of the underlying flow. See for example Table 1 at
https://petsymposium.org/2018/files/papers/issue4/popets-2018-0039.pdf#page=3
Tor pads most of its cells to 514 bytes (https://spec.torproject.org/tor-spec §0.2 §3),
and fairly recently (Tor 0.3.1.7, 2017-09-18) it sends padding cells
during quiet periods in order to collapse long-term netflow records
(https://spec.torproject.org/padding-spec §2), but neither of these are
designed to defend against website fingerprinting attacks; on the
contrary, they introduce fingerprints that make it easier to detect the
use of Tor inside a tunnel.

Don't miss an important use case. Tor and ESNI are not mutually
exclusive. A user may want to use ESNI in order to *reach* Tor (or any
other service offering additional security properties). ESNI is not just
for HTTPS web pages; it's for any TLS service (or service that can be
tunnelled in TLS). But any such service is useless if an intermediary
can block the server hosting it. This is where ESNI can be of help.

I wouldn't put repeated trials to infer a randomized value, and analysis
of encrypted application-layer traffic characteristics, in the same
class of difficulty, and reason that if the latter is possible, there's
no reason to defend against the former. I think part of the reason that
Tor does not (yet) do traffic flow obfuscation is that it hasn't been
necessary. The networks that block Tor don't do it on that basis. That's
not to say it's not something to think about, just that empirically it
hasn't proven as pressing as other considerations. Things like Cisco ETA
(https://www.theregister.co.uk/2017/06/22/ciscos_encrypted_traffic_fingerprinting_turned_into_product/,
https://github.com/cisco/joy#relation-to-cisco-eta, https://arxiv.org/abs/1607.01639)
show the commercial world at least reaching for such capabilities, but
my understanding is that it's still far short of an operational
"identify this HTTPS site" feature.