IETF Logo Mail Archive

Re: [TLS] ESNI padding the Certificate message

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 13 December 2018 16:02 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 5D5ED128CFD for <tls@ietfa.amsl.com>; Thu, 13 Dec 2018 08:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zvbfh5NzvwWV for <tls@ietfa.amsl.com>; Thu, 13 Dec 2018 08:02:56 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406091271FF for <tls@ietf.org>; Thu, 13 Dec 2018 08:02:56 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 80780AE0B6; Thu, 13 Dec 2018 11:02:54 -0500 (EST)
Date: Thu, 13 Dec 2018 11:02:54 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20181213160254.GJ79754@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <876187a2-df66-2eb0-5a55-b6e67cf668f6@cs.tcd.ie> <B3D20A93-3332-4541-8108-E4EFB08FBF6F@dukhovni.org> <CABcZeBM+ekw7xSzbz6Kh4aRbWXpy5f1U-iUu8W1fDKjVuUJ+3A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBM+ekw7xSzbz6Kh4aRbWXpy5f1U-iUu8W1fDKjVuUJ+3A@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Dno_l0vZv0kE4-ZJ0ekVl1imP-U>
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 16:02:59 -0000

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.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email