Re: [TLS] Certificate compression draft

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 06 March 2017 23:29 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 504DE129505 for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 15:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VjH7jGeOyd9s for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 15:29:27 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A171294ED for <tls@ietf.org>; Mon, 6 Mar 2017 15:29:27 -0800 (PST)
Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 61F607A32D8 for <tls@ietf.org>; Mon, 6 Mar 2017 23:29:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAAZdMaf9n_37soxdJ9ACFFke=iXyux82QEVnr5XgmS2bs2FTYA@mail.gmail.com>
Date: Mon, 6 Mar 2017 18:29:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <69B63AA2-EA81-4994-9E12-72F8B7945319@dukhovni.org>
References: <CAAZdMacAcSUL4sqLPA1E9-z_VaUSd1P5PpPryO+XQso0eUtThw@mail.gmail.com> <CABkgnnU54SeYDBL=YBRQn0ZThk=C59Rztvr2zkUCLSSv2cKTDg@mail.gmail.com> <CAAZdMaf9n_37soxdJ9ACFFke=iXyux82QEVnr5XgmS2bs2FTYA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Q0QKpWNDY7-6OXv4RgMb83LYDp0>
Subject: Re: [TLS] Certificate compression draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
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: Mon, 06 Mar 2017 23:29:28 -0000

> On Mar 6, 2017, at 6:23 PM, Victor Vasiliev <vasilvv@google.com> wrote:
> 
> Hi Martin,
> 
> I've measured the effect of compression on a corpus of popular website
> certificate chains I had lying around (Alexa Top 100k from a few years ago),
> and the effect seems to be about -30% of size at the median and -48% at 95th
> percentile (with Brotli, subtract 3-5% for zlib).
> 
> I think the most dramatic effect from the compression is observed for the
> certificates with a lot of SNI values, which is not uncommon.

Is 30-50% enough to mitigate concerns about amplification attacks?  Introducing
compression increases the attack surface on TLS clients and adds CPU cost.  If
the compression is not sufficiently effective, it is not clear that the benefit
outweighs the cost.

Wouldn't amplification be better addressed via TCP cookies?  With TCP fast open
restricted to cookie-bearing clients?  With similar mechanisms for UDP, ...

-- 
	Viktor.