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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XOInxkb3_pWg4zoAgDRmWIbN73o>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt
Precedence: list



> On Dec 9, 2017, at 07:43, Ilari Liusvaara <ilariliusvaara@welho.com> =
wrote:
>=20
> On Sat, Dec 09, 2017 at 12:30:23PM +0000, Alessandro Ghedini wrote:
>> Hello,
>>=20
>> Sorry for the long delay from the last update.
>>=20
>> On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-drafts@ietf.org =
wrote:
>>>=20
>>> 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.
>>>=20
>>>        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
>>>=20
>>> Abstract:
>>>   In Transport Layer Security (TLS) handshakes, certificate chains
>>>   often take up the majority of the bytes transmitted.
>>>=20
>>>   This document describes how certificate chains can be compressed =
to
>>>   reduce the amount of data transmitted and avoid some round trips.
>>=20
>> Here are the changes in this update, based on previous discussions:
>>=20
>> * 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.
>=20
> 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 =E2=80=9Cnegotiate=
d=E2=80=9D compression isn=E2=80=99t always used?  I.e.,=20

OLD:

   =E2=80=A6 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).
>=20
> Where is the client certificate compression algorithm signaled?

Correct me if I=E2=80=99m 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=