IETF Logo Mail Archive

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

Hanno Böck <hanno@hboeck.de> Tue, 06 June 2017 14:23 UTC

Return-Path: <hanno@hboeck.de>
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 DBC7A129461 for <tls@ietfa.amsl.com>; Tue, 6 Jun 2017 07:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3ZS5stG-C1zX for <tls@ietfa.amsl.com>; Tue, 6 Jun 2017 07:23:29 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC7012025C for <tls@ietf.org>; Tue, 6 Jun 2017 07:23:28 -0700 (PDT)
Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 06 Jun 2017 16:23:25 +0200 id 0000000000000045.000000005936BADD.000021E3
Date: Tue, 06 Jun 2017 16:23:24 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20170606162324.4aee493b@pc1>
In-Reply-To: <B3FAE1B5-E608-489F-B3B9-BC966B673D94@sn3rd.com>
References: <B3FAE1B5-E608-489F-B3B9-BC966B673D94@sn3rd.com>
X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/64DugoF_FY6ymKGvox0gQPK_3ZI>
Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 06 Jun 2017 14:23:32 -0000

On Tue, 6 Jun 2017 09:20:03 +0200
Sean Turner <sean@sn3rd.com> wrote:

> I appears that we’ve got enough consensus/interest to adopt
> draft-ghedini-tls-certificate-compression-00 based on the WG session
> in Chicago and this thread:

Hi,

one aspects brought up in that thread was that there is already RFC
7924, which allows certificate caching. There's also AIA, which allows
a client to fetch intermediate certificates, however as far as I can
see there's no way for a server to decide whether a client supports AIA.

All of these technologies seem to try to tackle the same problem:
reduce the burden of transmitting certificates.

I wonder if there should be more a big picture discussion here. If
clients have a good way of caching certificates - would that mean
transmitting them is so rare that compressing becomes unnecessary?

Also regarding 7924: I tried to find out what server and client software
supports that. I didn't find anything. One could see that as an
indication that it's not a big deal after all. If people are concerned
about the data wasted by transmitting certificates, I wonder if it
wouldn't be a more important issue to implement the already existing
tech that's available instead of inventing new tech.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

v2.23.0 | Report a Bug | By Email