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

From: Sean Turner <[email-masked]>
Date: Thu, 1 Feb 2018 10:38:34 -0500

> On Jan 31, 2018, at 16:41, Benjamin Kaduk <[email-masked]> wrote:
> 
>> I also wondered whether there was any sense in reserving codepoint 0 (of
>> CertificateCompressionAlgorithm) for "uncompressed".  I guess not, since
>> support for uncompressed certificates is implicit by means of not using
>> the extension.  But sometimes keeping value 0 (basically) reserved is
>> still useful.
>> 
>> I've considered that, but decided that this would just introduce two ways to do
>> the same thing (send certificate uncompressed), so I decided against it.
> 
> Sure.  I don't see a reason to add a code point for uncompressed, but maybe there is an aesthetic argument for leaving 0 reserved entirely.  But I definitely do not insist on anything.

We could just reserve it and not assign any meaning to it.

spt

---

From: Sean Turner <[email-masked]>
Date: Fri, 2 Feb 2018 09:25:11 -0500

> On Jan 26, 2018, at 05:26, Alessandro Ghedini <[email-masked]> wrote:
> 
> Me and Victor would like to ask for early codepoints assignment again, if you
> think we are ready now.

This now on the chair’s list of things to do.  It’s been a week and nobody has complained so I’m thinking the draft is on the right track.   Got one question before we start the RFC7120-dictated early code point assignment dance:

Q. What’s the plan for the dictionary?  Is a field going to be included later to indicate which one is in use, or is the dictionary going to be linked to the extension number and a new one will be minted when the dictionary is updated?

I got some other minor nits (I’ll submit them in GH but thought I’d include them here as well):

0) s4: includes the following:

   If the format of the Certificate message is altered using the
   server_certificate_type extension [RFC7250], the resulting altered
   message is compressed instead.

Shouldn’t it also mention client_certificate_type?

1) Is it worth expanding a bit on the text quoted above to note that it’s more than just altering the message it’s also about changing how the authentication messages are computed?  E.g., CertificateVerify is now Transcript-Hash(Handshake Context, CompressedCertificate).

2) Likewise, is it worth noting that in TLS 1.3 currently using compression on CertificateType.RawPublicKey is not going yield much in the way of compression?  Is it worth saying that future values of CertificateType should indicate whether compression is a good idea or not?

3) s7.3: to match the table:

OLD:

   The values in this registry shall be allocated under "IETF Review"
   policy for values strictly smaller than 64, and under "Specification
   Required" policy otherwise (see [RFC8126] for the definition of
   relevant policies).

NEW:

   The values in this registry shall be allocated under "IETF Review"
   policy for values strictly smaller than 64, under "Specification
   Required" policy for values 64-223, and under “Private Use”
   otherwise (see [RFC8126] for the definition of relevant policies).

4) s7.3: probably worth adding how to get one under the spec required:

   The procedures for requesting values in the Specification Required
   space are specified in [ID.tls-iana-registry-updates].

Our AD/IANA will ask later who is the expert (experts are implied as part of Spec Required), so how about we use the existing expert pool.

Note that the above 4 nits I don’t think really affect whether the early code point assignment starts.

spt

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 5 Feb 2018 13:32:57 -0500

On Fri, Feb 2, 2018 at 9:25 AM, Sean Turner <[email-masked]> wrote:

> This now on the chair’s list of things to do.  It’s been a week and nobody
> has complained so I’m thinking the draft is on the right track.   Got one
> question before we start the RFC7120-dictated early code point assignment
> dance:
>
> Q. What’s the plan for the dictionary?  Is a field going to be included
> later to indicate which one is in use, or is the dictionary going to be
> linked to the extension number and a new one will be minted when the
> dictionary is updated?
>

The plan is to allocate a new algorithm codepoint for each (compression
method, dictionary) tuple.  I don't want to decouple them, because it turns
out that for different algorithms the dictionary can be supplied in
different ways, and thus the actual content for the dictionary may vary.

(I'll address the nits a little bit later)

---

From: Sean Turner <[email-masked]>
Date: Tue, 6 Feb 2018 10:19:38 -0500

> On Feb 5, 2018, at 13:32, Victor Vasiliev <[email-masked]> wrote:
> 
> The plan is to allocate a new algorithm codepoint for each (compression method, dictionary) tuple.  I don't want to decouple them, because it turns out that for different algorithms the dictionary can be supplied in different ways, and thus the actual content for the dictionary may vary.
> 

I can live with this approach because it’s better than minting a new extension every time.  But just for the record then the code points we’re looking to assign now are “no dictionary”.

spt

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 8 Feb 2018 21:43:07 +0000

On Wed, Jan 31, 2018 at 03:41:34PM -0600, Benjamin Kaduk wrote:
> On 01/30/2018 04:02 PM, Victor Vasiliev wrote:
> Sure.  I don't see a reason to add a code point for uncompressed, but
> maybe there is an aesthetic argument for leaving 0 reserved entirely. 
> But I definitely do not insist on anything.

Yeah, makes sense to keep 0 reserved. I made a PR for this:
https://github.com/tlswg/certificate-compression/pull/12

and looks like Victor already merged it.

Cheers

---

From: Olivier Levillain <[email-masked]>
Date: Wed, 14 Feb 2018 10:19:58 +0100

Hi list,

Le 26/01/2018 à 11:18, [email-masked] a écrit :
> 
> 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-02.txt
> 	Pages           : 7
> 	Date            : 2018-01-26

I am sorry I am late in the process of commenting this draft, but I have
a question about the CompressedCertificate message: why does it contain
an uncompressed_length field?

What is the point of this field which can not be trusted? If the idea is
to give a hint of how long a certificate is, we already know that.

Since the whole goal of this draft is to reduce the size of the message,
I would strongly suggest this field be removed. It is too much a
temptation to be considered as a reliable information for shaky
implementations.

Best regards,
Olivier Levillain

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 14 Feb 2018 17:32:09 +0200

> an uncompressed_length field?

To know beforehand how much memory to allocate so one is able to
perform oneshot decompression.
 
> to give a hint of how long a certificate is, we already know that.

The compression ratio can vary.

> temptation to be considered as a reliable information for shaky

It actaully makes writing solid decompressors easier. At least if the
decompressor API is at least as good as zlib.

If you know the sizes up front, you can do the decompression in one shot,
and check that the availables are zero afterwards. Compare this with messing
with variable-sized buffers. The chances of mistake are greatly increased if
one has to resize buffers.

-Ilari