Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 09 December 2017 12:43 UTC

Return-Path: <ilariliusvaara@welho.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 021A9128BA2 for <tls@ietfa.amsl.com>; Sat, 9 Dec 2017 04:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 lrgTNpoHG13r for <tls@ietfa.amsl.com>; Sat, 9 Dec 2017 04:43:41 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0149126D0C for <tls@ietf.org>; Sat, 9 Dec 2017 04:43:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 26EC097A23 for <tls@ietf.org>; Sat, 9 Dec 2017 14:43:39 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Gp4GVV1gq6cv for <tls@ietf.org>; Sat, 9 Dec 2017 14:43:38 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A514D72 for <tls@ietf.org>; Sat, 9 Dec 2017 14:43:37 +0200 (EET)
Date: Sat, 9 Dec 2017 14:43:37 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20171209124337.GA7162@LK-Perkele-VII>
References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20171209123023.GA8296@pinky>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/x9b_FC1E1H9JMmcbyy5zhYYc-ME>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt
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: Sat, 09 Dec 2017 12:43:44 -0000

On Sat, Dec 09, 2017 at 12:30:23PM +0000, Alessandro Ghedini wrote:
> Hello,
> 
> Sorry for the long delay from the last update.
> 
> On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-drafts@ietf.org wrote:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> > 
> >         Title           : Transport Layer Security (TLS) Certificate Compression
> >         Authors         : Alessandro Ghedini
> >                           Victor Vasiliev
> > 	Filename        : draft-ietf-tls-certificate-compression-01.txt
> > 	Pages           : 7
> > 	Date            : 2017-12-09
> > 
> > Abstract:
> >    In Transport Layer Security (TLS) handshakes, certificate chains
> >    often take up the majority of the bytes transmitted.
> > 
> >    This document describes how certificate chains can be compressed to
> >    reduce the amount of data transmitted and avoid some round trips.
> 
> Here are the changes in this update, based on previous discussions:
> 
> * Defined a new CompressedCertificate message instead of re-defining the
>   contents of Certificate. Applications can decide to send a compressed
>   certificate using this new message, or keep sending the normal uncompressed
>   Certificate.

The section 3 on extension still seems to be written like Certificate
message was still used.

> * Added support for client certificates. Both server and client-side support is
>   negotiated using the same "compress_certificates" extension, but given the
>   previous change, client and server can negotiate compression and only decide
>   to receive compressed certificates rather than send them (i.e. a client or
>   server is only required to implement decompression).

Where is the client certificate compression algorithm signaled?


-Ilari