Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 27 November 2016 20:20 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 A143212953C for <tls@ietfa.amsl.com>; Sun, 27 Nov 2016 12:20:03 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 6nojCj8MLgZV for <tls@ietfa.amsl.com>; Sun, 27 Nov 2016 12:20:02 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2B7129527 for <tls@ietf.org>; Sun, 27 Nov 2016 12:20:01 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F691284EA9; Sun, 27 Nov 2016 20:20:00 +0000 (UTC)
Date: Sun, 27 Nov 2016 20:20:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20161127202000.GA26244@mournblade.imrryr.org>
References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <CABcZeBO-7F-s-jtOj7FLO7kko3B+s9TyyO9WaL2MkvtN9JqYbw@mail.gmail.com> <CAAZdMacBDy0tbRvu0zR5FShm-nFZB0FmoSsoB3vT2HqTRPqLLA@mail.gmail.com> <20161127151304.gaqxot5wqcmcey7n@pinky.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20161127151304.gaqxot5wqcmcey7n@pinky.local>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sacjpGSSlAsbna_LMMOHJsEYiN4>
Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: 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: Sun, 27 Nov 2016 20:20:03 -0000

On Sun, Nov 27, 2016 at 03:13:04PM +0000, Alessandro Ghedini wrote:

> On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> > I am currently trying to figure out how much of QUIC certificate
> > compression can be adapted to work with TLS.  I will submit a draft as soon
> > as I have a working prototype.
> 
> FWIW I too have started working on a prototype for gzip compressing certificates
> based on BoringSSL:
> https://github.com/ghedo/boringssl/tree/cert_compress
> 
> It's not complete yet and I only implemented compression so far based on what
> Chromium does with QUIC. I also haven't really tested it yet (but at least it
> builds AFAICT :) ).
> 
> I'd like to do some tests as well to measure the benefits of this (e.g.
> download certificates from CT logs and see how effective the compression is).

My concerned is that any packet size benefit from compressing
certificates with gzip is likely not worth the CPU cost and attack
surface of performing the compression and uncompression.

FWIW, my long-standing practice is to not link the SSL library with
zlib.  I was doing this as a matter of hygiene, long before the
various attacks on (application payload) compression were reported.

-- 
	Viktor.