Subject: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

From: Sean Turner <[email-masked]>
Date: Wed, 23 May 2018 21:23:10 -0400

IANA has assigned the following values:

1) In the ExtensionType Values registry, the following entry was added:

26	compress_certificate (TEMPORARY - registered 2018-05-23, expires 2019-05-23)	[draft-ietf-tls-certificate-compression]

Please see
https://www.iana.org/assignments/tls-extensiontype-values

2) In the TLS HandshakeType Registry, the following entry was added:

25	compressed_certificate (TEMPORARY - registered 2018-05-23, expires 2018-05-23)	DTLS-OK: Y	[draft-ietf-tls-certificate-compression]

Please see
https://www.iana.org/assignments/tls-parameters

NOTE: IANA can’t create the registry for the compression algorithms until the document is approved by the IESG, but Ben (and the chairs) figured we didn’t really need that to get this going.  If additional compression algorithms start to get used, let’s make sure to note what they are.

spt

>> From: Sean Turner <[email-masked]>
>> Subject: early code point assignment for draft-ietf-tls-certificate-compression
>> Date: April 23, 2018 at 12:33:08 EDT
>> To: TLS WG <[email-masked]>
>> 
>> All,
>> 
>> tl;dr: If you object to the following early code point assignments 1) add the compress_certificate in the TLS ExtensionType Registry and 2) compressed_certificate in the TLS HandshakeType Registry, then please let the list know why by 2359UTC on 10 May 2018.  The Certificate Compression Algorithm IDs will be populated with two values: zlib and brotli.
>> 
>> At IETF101, we discussed beginning the process of getting an early code point assignment for the extension defined in draft-ietf-tls-certificate-compression.  The one technical comments raised at the meeting was extending the compression code point space from 1 byte to 2 might be a good idea.  The authors have merged a PR to address this in the gh repo and once they submit a new version of the draft the process for an early code point assignment will begin.  The rules for this are specified in RFC7120, and the four criteria for a draft to be eligible for early code point assignment are:
>> 
>> Criteria A
>> 
>>       The code points must be from a space designated as "RFC
>>       Required", "IETF Review", or "Standards Action".  Additionally,
>>       requests for early assignment of code points from a
>>       "Specification Required" registry are allowed if the
>>       specification will be published as an RFC.
>> 
>> The Transport Layer Security (TLS) Extensions and TLS HandshakeType Registry registries are both RFC Required.  While we’re changing that registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still every intention to publish draft-ietf-tls-certificate-compression as an RFC so we’re still good to go.
>> 
>> Criteria B
>> 
>>       The format, semantics, processing, and other rules related to
>>       handling the protocol entities defined by the code points
>>       (henceforth called "specifications") must be adequately described
>>       in an Internet-Draft.
>> 
>> When asked at IETF101 what other outstanding comments there were on the draft the only one identified was increasing the code point size for the compression algorithms.  Version -05 will address this point.
>> 
>> Criteria C
>> 
>>       The specifications of these code points must be stable; i.e., if
>>       there is a change, implementations based on the earlier and later
>>       specifications must be seamlessly interoperable.
>> 
>> At IETF101, it was noted that this specification was stable enough.  Implementation issues might be identifier later, but, well, that’s the point.
>> 
>> Criteria D
>> 
>>       The Working Group chairs and Area Directors (ADs) judge that
>>       there is sufficient interest in the community for early (pre-RFC)
>>       implementation and deployment, or that failure to make an early
>>       allocation might lead to contention for the code point in the
>>       field.
>> 
>> 5 WG participants all from different organizations indicated their interest in implementing this draft (even if it was just for experimentation).
>> 
>> 
>> There are also 6 steps identified in RFC 7120 for early assignment, but only four involve the chairs:
>> 
>>  1.  The authors (editors) of the document submit a request for early
>>       allocation to the Working Group chairs, specifying which code
>>       points require early allocation and to which document they should
>>       be assigned.
>> 
>> An in-person request was made at IETF 101 for the early code point assignments.  There was also an earlier on-list request.
>> 
>>   2.  The WG chairs determine whether the conditions for early
>>       allocations described in Section 2 are met, particularly
>>       conditions (c) and (d).
>> 
>> The chairs agree that the four conditions have been met.
>> 
>>   3.  The WG chairs gauge whether there is consensus within the WG that
>>       early allocation is appropriate for the given document.
>> 
>> The sense of the room at IETF 101 was that yes early allocation is appropriate, but this email is verifying that.
>> 
>>   4.  If steps 2) and 3) are satisfied, the WG chairs request approval
>>       from the Area Director(s).  The Area Director(s) may apply
>>       judgement to the request, especially if there is a risk of
>>       registry depletion.
>> 
>> Once the chairs have determined WG consensus, we’ll pass it to Ben.
>> 
>> spt
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 May 2018 03:23:36 +0000

>26      compress_certificate (TEMPORARY - registered 2018-05-23, expires 2019-05-23)    [draft-ietf-tls-certificate-compression]

That's going to cause clashes with implementations that use that value for
TLS-LTS, it would be better to use a value other than 26 that isn't already in
use.

Peter.

---

From: Adam Langley <[email-masked]>
Date: Thu, 24 May 2018 09:30:59 -0700

> TLS-LTS, it would be better to use a value other than 26 that isn't
already in

Obviously I'm not adverse to using the occasional, non-IANA code point. But
they need to be picked randomly and outside the dense, IANA area.
Otherwise, this is certain to happen in short order.

I think quite a lot of clients are going to be advertising compression
using this code point in the coming months. They should only do so when
offering TLS 1.3, which presumably LTS clients would not, so maybe there's
something you could use there.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Hubert Kario <[email-masked]>
Date: Thu, 24 May 2018 18:48:07 +0200

> something you could use there.

speaking of TLS-LTS, would reigniting that discussion be good idea now, or 
should we wait for the TLS 1.3 to be officially published?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 May 2018 12:51:08 -0400

> On May 24, 2018, at 12:30 PM, Adam Langley <[email-masked]> wrote:
> 

It might still be prudent to get the new code point re-assigned.  I
can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS
preferred when using TLS 1.2.

-- 
	Viktor.

---

From: Adam Langley <[email-masked]>
Date: Thu, 24 May 2018 10:42:07 -0700

> preferred when using TLS 1.2.

It's also been pointed out that 26 collides with the value in
https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by
Sean :)

So we have a triple collision on 26, albeit with one candidate being much
more official.

Sean: do you want to kick quic_transport_parameters off 26 then? Move it to
a high, random value until assigned?

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 May 2018 14:46:26 -0500

> Otherwise, this is certain to happen in short order.

Why can't we make it so IANA does early codepoint assignment?

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 May 2018 14:54:44 -0500

> Why can't we make it so IANA does early codepoint assignment?

They already do, and we've got documents approved by the IESG that make the
registration policy just "specification required" (as opposed to "IETF review").

While Peter did mention the value 26 on the list two years ago, there hasn't exactly
been a lot of visible action with TLS-LTS in the intervening period...

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 May 2018 13:14:52 -0700

> a high, random value until assigned?

I don't think it's a problem if QUIC moves. Let's just do a fast early code
point assignment for that.....

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 May 2018 09:45:45 +1000

> I don't think it's a problem if QUIC moves. Let's just do a fast early
code point assignment for that.....

Yeah, on the scale of things that are about to change in QUIC, this is of
marginal concern.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 May 2018 00:35:50 +0000

Adam Langley <[email-masked]> writes:

>they need to be picked randomly and outside the dense, IANA area. Otherwise,
>this is certain to happen in short order.

The story behind this one was that I was asked to defer publication of -LTS
until the IANA registry draft got published (and I'm still waiting).  In the
meantime implementers needed to use some value for deployments, and 26 was the
next unused value so that got used under the assumption that if everything
else was also waiting for the registry draft to be published it wouldn't get
grabbed away suddenly.  It's now been in use for about two years so there is
quite a bit of precedent for its use by LTS.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 May 2018 00:38:51 +0000

>should we wait for the TLS 1.3 to be officially published?

In the past I've been asked to (1) wait until 1.3 is published and (2) wait
till the registry update draft is published.  Since both have dragged on and
on, LTS has been sitting there forever, a bit like the SCEP draft, with
deployments based on a perpetual draft.  I'd be quite happy to get it finally
published and resolve the status.  SCEP took eighteen years, I don't quite
want to go to that level...

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 May 2018 20:40:27 -0400

> On May 24, 2018, at 8:35 PM, Peter Gutmann <[email-masked]> wrote:
> 

This is perhaps sufficient reason to change the compression assignment.
It sure looks like Peter did the right thing in good faith, and at
this time, the LTS use should I think be grandfathered in.  Are there
(m)any implementations shipped that already have 26 for compression?

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 May 2018 01:06:18 +0000

>https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by

I think that registry draft really needs to get published... anyone else on
26?

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 May 2018 21:10:38 -0500

> I think that registry draft really needs to get published... anyone else on

(The authors just today published a new rev of the draft that is believed to have
addressed all IESG comments and be ready for approval.)

-Ben
(with AD hat)

---

From: Hubert Kario <[email-masked]>
Date: Fri, 25 May 2018 13:03:45 +0200

On Thursday, 24 May 2018 21:54:44 CEST Benjamin Kaduk wrote:
> > > > TLS-LTS, it would be better to use a value other than 26 that isn't
> > > 
> > > already in
> > > 
> > > > use.
> > > 
> While Peter did mention the value 26 on the list two years ago, there hasn't
> exactly been a lot of visible action with TLS-LTS in the intervening
> period...

because the chair(s) position was that it would be detracting from TLS 1.3 
work, not because the problem went away

---

From: Hubert Kario <[email-masked]>
Date: Fri, 25 May 2018 13:15:58 +0200

> preferred when using TLS 1.2.

I personally would prefer a different approach to TLS-LTS than what was 
proposed then, so what uses ext 26 now may very well not be compatible with 
the RFC'd version... don't know how much of a problem would it be to 
implementations that Peter shipped

and yes, IMNSHO the TLS-LTS makes sense only in case the modern stacks (i.e. 
ones that support TLS 1.3) also support it and prefer it over vanilla TLS 1.2

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 May 2018 08:37:17 -0400

> On May 24, 2018, at 13:42, Adam Langley <[email-masked]> wrote:
> 

f2p (face to plam).

spt

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 31 May 2018 19:37:52 -0700

Since there is a conflict with deployments with extension code point 26
IANA has now assigned the compress_certificate extension code point 27 from
the TLS extensionType values registry.

On Wed, May 23, 2018 at 6:23 PM, Sean Turner <[email-masked]> wrote:

> 26      compress_certificate (TEMPORARY - registered 2018-05-23, expires
> 2019-05-23)    [draft-ietf-tls-certificate-compression]
>
> Please see
> 25      compressed_certificate (TEMPORARY - registered 2018-05-23, expires
> 2018-05-23)  DTLS-OK: Y      [draft-ietf-tls-certificate-compression]
>
> Please see
> NOTE: IANA can’t create the registry for the compression algorithms until
> the document is approved by the IESG, but Ben (and the chairs) figured we
> didn’t really need that to get this going.  If additional compression
> algorithms start to get used, let’s make sure to note what they are.
>
> spt
>
> >> tl;dr: If you object to the following early code point assignments 1)
> add the compress_certificate in the TLS ExtensionType Registry and 2)
> compressed_certificate in the TLS HandshakeType Registry, then please let
> the list know why by 2359UTC on 10 May 2018.  The Certificate Compression
> Algorithm IDs will be populated with two values: zlib and brotli.
> >>
> >> At IETF101, we discussed beginning the process of getting an early code
> point assignment for the extension defined in draft-ietf-tls-certificate-compression.
> The one technical comments raised at the meeting was extending the
> compression code point space from 1 byte to 2 might be a good idea.  The
> authors have merged a PR to address this in the gh repo and once they
> submit a new version of the draft the process for an early code point
> assignment will begin.  The rules for this are specified in RFC7120, and
> the four criteria for a draft to be eligible for early code point
> assignment are:
> >>
> >> Criteria A
> >>
> >> The Transport Layer Security (TLS) Extensions and TLS HandshakeType
> Registry registries are both RFC Required.  While we’re changing that
> registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still
> every intention to publish draft-ietf-tls-certificate-compression as an
> RFC so we’re still good to go.
> >>
> >> Criteria B
> >>
> >> When asked at IETF101 what other outstanding comments there were on the
> draft the only one identified was increasing the code point size for the
> compression algorithms.  Version -05 will address this point.
> >>
> >> Criteria C
> >>
> >> At IETF101, it was noted that this specification was stable enough.
> Implementation issues might be identifier later, but, well, that’s the
> point.
> >>
> >> Criteria D
> >>
> >> 5 WG participants all from different organizations indicated their
> interest in implementing this draft (even if it was just for
> experimentation).
> >>
> >>
> >> An in-person request was made at IETF 101 for the early code point
> assignments.  There was also an earlier on-list request.
> >>
> >> The sense of the room at IETF 101 was that yes early allocation is
> appropriate, but this email is verifying that.
> >>