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

Sean Turner <sean@sn3rd.com> Sun, 10 December 2017 18:58 UTC

Return-Path: <sean@sn3rd.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 14E6D1276AF for <tls@ietfa.amsl.com>; Sun, 10 Dec 2017 10:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 KSgVeaLjqeHW for <tls@ietfa.amsl.com>; Sun, 10 Dec 2017 10:57:58 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407A61200FC for <tls@ietf.org>; Sun, 10 Dec 2017 10:57:58 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id m59so32952730qte.11 for <tls@ietf.org>; Sun, 10 Dec 2017 10:57:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wdn8W15UTiFmAy6B3qaC8pYp23Bpn9MYYm6OcA6jGU=; b=nBWKvCmpdizo2VFzc4piLZxqhWXLdDKgkR1aWMeqDznvs8IhsoZhvvqlp3aAphQw8G 5Tzy59PLqE+dXbxvYQxbwCHBCj8/fWqA652i5iIF+zOtEfcqA6Mixs5M6Myestk/OgQe h0r0D5gbkxUZbuw4cTl8T+61k6LiHg4O+YVM0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wdn8W15UTiFmAy6B3qaC8pYp23Bpn9MYYm6OcA6jGU=; b=eMDYZpm8vOQ0UyqXZ4nqDpjvaQsHScuFs+xZMGcHx+ry1JIhIzh506BKKMhS7/v9Eq BYigqSwFSSiKsSnpbFM4KQaN431TXBksrWFFwaPym094YqDvPAKuWHPfWCO1/UejFGgz J8wUTXBYWLteq30R7S1oA7FULmZsPLQ5wqhEectDlq3PbmO8aXd0xTd/2jKv4CXxws9+ hfZqORo+y/h1oystwTZeU0lO9cHENChgIXOg44UBVduTFChMBB4JHKaEGmDEYUBSHRGL fyyrUjvdi0+V1dAO/djiLbeASv8DdkQLvNPIQ0mD8uYsL/2ZpZVVMjnxQx9GK0y63QpO +BqA==
X-Gm-Message-State: AKGB3mLnxYbHBUniSSzPEjKhI01LUkk/q4Oy7/Qi3Rtoe12hLKsfMLEx O2//rNgkPzmyAW5lkk7ctrZwYRgcZ1Y=
X-Google-Smtp-Source: AGs4zMa9d+jPkNSArdv7pC+g0ihU6Q2X9k6VhDbb1eZW93JezUCapLds3Ivr/fleB9WntxVXlERWgw==
X-Received: by 10.55.89.68 with SMTP id n65mr43377390qkb.187.1512932277207; Sun, 10 Dec 2017 10:57:57 -0800 (PST)
Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id r33sm3123024qte.36.2017.12.10.10.57.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 10:57:56 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <20171209124337.GA7162@LK-Perkele-VII>
Date: Sun, 10 Dec 2017 13:57:54 -0500
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DACA4DB-7083-4355-BB43-AF65A4414C71@sn3rd.com>
References: <151282209956.24790.5482932813219061171@ietfa.amsl.com> <20171209123023.GA8296@pinky> <20171209124337.GA7162@LK-Perkele-VII>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XOInxkb3_pWg4zoAgDRmWIbN73o>
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: Sun, 10 Dec 2017 18:58:00 -0000


> On Dec 9, 2017, at 07:43, Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
> 
> 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.

Are you suggesting a subtle wording change because once “negotiated” compression isn’t always used?  I.e., 

OLD:

   … which is used by the client and the
   server to negotiate the use of compression for their certificate
   chains, as well as the choice of the compression algorithm. ...

NEW:

   .. which is used by the client and the
   server to negotiate the *possible* use of compression for their certificate
   chains, as well as the choice of the compression algorithm. ...

>> * 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?

Correct me if I’m wrong, but I think the assumption here is that if the client offers both zlib and brotli and the server returns brotli that the client (if it does choose to compress) will use the same algorithm the server chose.

spt