Subject: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

From: The IESG <[email-masked]>
Date: Fri, 25 May 2018 12:56:11 -0700

The IESG has approved the following document:
- 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram
   Transport Layer Security (DTLS)'
  (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working Group.

The IESG contact persons are Benjamin Kaduk and Eric Rescorla.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/

Technical Summary

This document is not very technical, it's about IANA registries:

   This document describes a number of changes to (D)TLS IANA registries that
range from adding notes to the registry all the way to changing the
registration policy.  These changes were motivated by WG review of the
(D)TLS-related registries undertaken as part of the TLS1.3 development process.
This document updates many (D)TLS RFCs 3749, 5077, 4680, 5246, 5705, 5878,
6520, and 7301.

Working Group Summary

 This draft has been discussed at multiple IETFs most recently at IETF100:
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-iana-registry-updates/
 
 There's not been a lot of review because most people consider this
administrivia that others should do; most just want the rules relaxed.  A
couple of notable reviews have been provided as noted below.

The most important change - to loosen registrations while at the same
time adding a "recommended" column to key registries requiring standards
action for a "yes" value, had clear WG consensus.

Various other WG documents depend on these changes being made and more will in
the near future.

Document Quality

This document is essentially administrative, so the important considerations are to
ensure consistency amongst it, the TLS 1.3 spec, and the existing registry contents,
as well as internal consistency about the handling for various attributes, such as the
"Recommended" column, warning notes to be added to registries, and review policies.
Martin Thomson and Eric Rescorla have reviewed previous versions of the document.

Personnel

   Stephen Farrell is the  Document Shepherd.
   Benjamin Kaduk is the Responsible Area Director.

   The IANA Expert(s) for the registries
   in this document are:
     Yoav Nir <[email-masked]>, 
     Rich Salz <[email-masked]>, and 
     Nick Sullivan <[email-masked]> .
  The named experts have been approved previously
  on the March 8, 2018 Formal telechat.

RFC Editor Note

Section 15 mentions "values with the first byte in the range" (twice), but there is only a single byte,
so these should just be "values in the range".

Please also note that the traditional "IANA shall do/has done" constructions to be resolved to the
past tense appear throughout the document, not just in an IANA considerations section.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 27 May 2018 12:49:51 +0000

>  (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard

Now that it's been published, I'd like to request assignment of an extension
ID for tls_lts under the Specification Required terms.

In terms of the conflict between the existing use of 26 = tls_lts and the new
26 = compress_certificate, this can probably be managed by noting that
compress_certificate will only be sent by TLS 1.3 implementations and tls_lts
will only be sent by TLS 1.0-1.2 implementations.  In addition
compress_certificate has a nonzero size (a list of algorithms is sent) while
tls_lts has a zero size (it's an indicator flag).  This means that the two
different uses are unlikely to occur in the same implementation, and even if
they do can be distinguished by looking at the extension data size.

Having compress_certificate moved to 27 would be a better solution in terms of
existing use, but I can add a note to the LTS draft mentioning the change. The
certificate compression draft should probably also be updated to indicate that
a zero-size compress_certificate, if encountered, isn't a compress_certificate
but a tls_lts.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 May 2018 09:56:30 -0700

Well, this is a bit premature because the document hasn't actually been
published, just approved.

In any case, I don't think we should assign code point 26 to this
extension. I recognize that you have existing implementations that happen
to use it, but that's a result of the unfortunate decision to squat on a
code point which was right in the way of near future assignments, and those
implementations can change to the new code point. Of course, it might be
useful to add a note to implementations of the compression draft as well.

-Ekr

On Sun, May 27, 2018 at 5:49 AM, Peter Gutmann <[email-masked]>
wrote:

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 27 May 2018 17:57:54 +0000

>In any case, I don't think we should assign code point 26 to this extension. I recognize that you have existing implementations that happen to use it, but that's a result of the unfortunate decision to squat on a code point which was right in the way of near future assignments, and those implementations can change to the new code point. Of course, it might be useful to add a note to implementations of the compression draft as well.

I think, in the spirit of comity, we let 26 go to Peter’s draft.

                /r$

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 28 May 2018 04:38:44 +0000

Eric Rescorla <[email-masked]> writes:

>In any case, I don't think we should assign code point 26 to this extension.
>I recognize that you have existing implementations that happen to use it, but
>that's a result of the unfortunate decision to squat on a code point which
>was right in the way of near future assignments, and those implementations
>can change to the new code point. Of course, it might be useful to add a note
>to implementations of the compression draft as well.

See my previous comment on why it was used, it was only because implementers
needed something to put in their code while I waited for the registry draft to
be published... 

In any case I'm not overly fussed, as long as something gets assigned, just
wanted to point out that -LTS continuing with 26 would avoid having to
document the problem in two different drafts and adding hacks to code to deal
with it.  Given that one use is for SCADA/embedded TLS 1.0-1.2 and the other
is public web TLS 1.3 it's (hopefully) unlikely they'll ever run into each
other, but it'd be less messy if it was done properly rather than through
workarounds.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 May 2018 00:43:34 -0400

> On May 28, 2018, at 12:38 AM, Peter Gutmann <[email-masked]> wrote:
> 

I am curious whether (given the rather recent assignment) there are any shipping implementations of compression with 26 already baked in.  If not, then perhaps
TLS-LTS should get precedence.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 May 2018 15:14:14 -0500

> published, just approved.

It's also not properly addressed -- regular allocations under the
"specification required" policy go directly to IANA, whereas RFC 7120 early
allocations it is the WG chairs and ADs that need to judge the level of
interest in the community.

> useful to add a note to implementations of the compression draft as well.

There's a tradeoff between respecting the official allocation processes
and avoiding real-world breakage.  I think we can all make our own assessments
on the former, but for the latter, all the evidence we have so far is a claim
from Peter that there exists software that hardcodes this number, with no
indication of scale of deployment or ease of updating such software.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 May 2018 20:21:53 +0000

Peter tried very hard to play by all the rules, whether they were enshrined in formal documents, or "just" decisions by WG chairs, and everything in-between.

Peter says the number is in use.

I believe him.

Give him the damn number.

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 29 May 2018 21:15:47 -0400

> Give him the damn number.

+1.

I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
working group for their smart locks last year. I have no idea how much
of the code they are going to reuse (if any at all).

Jeff

---

From: Adam Langley <[email-masked]>
Date: Wed, 30 May 2018 20:13:02 -0700

> of the code they are going to reuse (if any at all).

Chrome / Google is blocked on code-point assignment for deploying
certificate compression. It appears that 26 is not a good pick and we
thus wait in anticipation for a replacement.

(The extensions space is effectively infinite: if we get close to
running out, we can assign an "extended extensions" code point, which
would contain a nested extensions block with 32-bit numbers instead.
Therefore effort and delays resulting from treating it as a scarce
resource are saddening. Speaking in a personal capacity, it looks like
26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
randomly to avoid issues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)

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

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 30 May 2018 22:56:03 -0700

I agree we should use a different number than 26 for certificate
compression.  I don't see a problem with assigning 27 and reserving 26 for
now.

---

From: David Benjamin <[email-masked]>
Date: Thu, 31 May 2018 10:42:24 -0400

I probed a bunch of servers yesterday and found evidence of yet another
collision at 26! It's possible these are TLS-LTS implementations, but a lot
of them additionally only support RSA decryption ciphers, which makes this
seem unlikely. These servers do not appear to do anything with the
extension, as far as I could tell, including even echoing it back, but
they  send decode_error if the extension includes a non-empty body. (It's
possible their TLS implementation supports TLS-LTS, unconditionally parses
the extension, but does not actually enable it by default.)

I didn't repeat the probe with 27, but playing with a couple of the servers
showed they tolerate other numbers fine, including 27. It's just that they
appear to have squatted on 26 for something.

It's frustrating that allocating code points is complicated, but given the
other deployment problems TLS has seen lately, were this the worst of our
problems, I would be quite happy.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 May 2018 07:50:46 -0700

Based on this, I propose that IANA allocates a new !26 Early Data code
point for compressed certificates (that's mechanical).

As noted earlier, it's premature for TLS-LTS to request a code point
because the enabling document has not yet been published, so we can defer
the question of its use of 26 for a bit.

The QUIC TLS extension should also change to a new code point, but I'm not
sure it meets the criteria for an early code point assignment. MT proposed
just squatting on a random code point. Having a really unique code point is
less important here because this extension will only appear inside of QUIC
and not on ordinarily TLS connections, though of course it must have a
unique code point from other extensions used with QUIC. So it's not
entirely clear how best to handle this,

-Ekr

On Thu, May 31, 2018 at 7:42 AM, David Benjamin <[email-masked]>
wrote:

> I didn't repeat the probe with 27, but playing with a couple of the
> servers showed they tolerate other numbers fine, including 27. It's just
> that they appear to have squatted on 26 for something.
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 31 May 2018 10:59:54 -0400

Just picking a random high number for QUIC seems reasonable for this stage.
None of this still will escape outside of draft QUIC versions (which,
themselves, will be short-lived) and a collision at high numbers isn't
likely anyway. Our problems with 26 and 40 are because we like to make
"official" allocations consecutively, and then "unofficial" allocations
missed the obvious corollary: do not mimic this.

On Thu, May 31, 2018 at 10:51 AM Eric Rescorla <[email-masked]> wrote:

>> It's frustrating that allocating code points is complicated, but given
>> the other deployment problems TLS has seen lately, were this the worst of
>> our problems, I would be quite happy.
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 May 2018 10:10:33 -0500

I think there's also some room to just mark 26 as "Reserved - unauthorized
use has rendered this value unsuitable for official allocation".

-Ben

---

From: Steven Valdez <[email-masked]>
Date: Thu, 31 May 2018 11:14:49 -0400

We might also want to mark 40 similarly given the ExtendedRandom collision
that caused issues with key_share.

On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk <bkaduk=
[email-masked]> wrote:

> the
> > >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley <[email-masked]
> >
> > >> wrote:
> > >>

-- 

Steven Valdez |  Chrome Networking |  [email-masked] |  210-692-4742

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 1 Jun 2018 02:05:50 +0000

​David Benjamin <[email-masked]> writes:

>seem unlikely. 

Another reason why it should be unlikely (emphasis on "should") is that the
use is in SCADA/embedded, so not anything that should be visible on the public
internet.

Having said that, someone sent me a link to a Shodan scan earlier today with
over a thousand devices that definitely shouldn't be on the Internet, so who
knows what's being put online there.

>These servers do not appear to do anything with the extension, as far as I
>could tell, including even echoing it back, but they  send decode_error if
>the extension includes a non-empty body.

Hmm, that does sounds like -LTS, since it has an empty body... no idea whose
implementation that would be though.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 1 Jun 2018 02:10:52 +0000

Eric Rescorla <[email-masked]> writes:

>As noted earlier, it's premature for TLS-LTS to request a code point because
>the enabling document has not yet been published, 

And yet -compression was allocated a codepoint without this.  This whole mess
was created because I asked for early allocation and was told to wait, which I
did [0], while -compression wasn't subject to the same requirements.

Peter.

[0] Meaning I didn't push the issue any further, however people were rolling
    out deployments and we had to use some value, see my previous comments 
    on why 26 was used.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 1 Jun 2018 02:13:28 +0000

David Benjamin <[email-masked]> writes:

>Our problems with 26 and 40 are because we like to make "official"
>allocations consecutively, and then "unofficial" allocations missed the
>obvious corollary: do not mimic this.

Yeah, based on being asked to wait for the registry draft I assumed nothing
would be issued until the registry draft was published.  If I'd known that
there'd be allocations made despite the draft not being published, I'd have
chosen a random value or something.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 May 2018 19:17:10 -0700

On Thu, May 31, 2018 at 7:10 PM, Peter Gutmann <[email-masked]>
wrote:

> because
> And yet -compression was allocated a codepoint without this.

Compression is a WG draft which met the standards for early allocation.
This is not
a WG draft, but will meet the new standard for regular allocation when the
IANA
document is published.

This whole mess
> did [0], while -compression wasn't subject to the same requirements.

I would say rather that this mess was created by your choosing to squat on
a code
point right in the middle of future allocations.

-Ekr