Subject: [TLS] IANA Considerations for draft-ietf-tls-dtls-connection-id

From: Sean Turner <[email-masked]>
Date: Thu, 20 Jun 2019 21:46:43 -0400

All,

During the DE’s review of the assignments for draft-ietf-tls-dtls-connection-id, they requested a new “DTLS Only” column be added to the TLS ExtensionType Values registry. This connection_id would be the only “Y” and all others there now would be “N”.

The chairs also noted that the IANA considerations in draft-ietf-tls-dtls-connection-id needs to specify values for all the columns for connection_id in the TLS ExtensionType Values registry and tls12_cid in the TLS ContentType registry.  Here are the proposed values:

connection_id
	TLS 1.3 column: “-“ it is not applicable to TLS 1.3
	Recommended: “Y"

tls12_cid
	DTLS-OK: “Y”

This has been captured in the following PR:
https://github.com/tlswg/dtls-conn-id/pull/67

Obviously, please comment.

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 26 Jun 2019 13:32:13 -0400

While these IANA points are minor, what is being considered here affects all TLS registries so please let us know what you think about the proposal for the following issue:

Issue:

The IANA DEs (Designated Experts) think that the registry should indicate that the connection_id  is DTLS-Only.  This is the first extension defined that would need this marking.  Currently, there is no “DTLS-Only” column in the TLS ExtensionType Values registry nor is there a "DTLS-OK" column like there are in the TLS Parameter registries [0].  Note none of the TLS extension registries [1] have a "DTLS-OK” column.

Proposals (there might be more):

0. Do nothing

1. Add a note to the top of the registry that says connection_id is DTLS-Only

2. Add a DTLS-Only column to the TLS ExtensionType Values registry and mark this one Y and all others N

3. Think about the future (inspired by Achiem in the GH repo):

- Change the “DTLS-OK” column to "TLS/DTLS”.  Allow values of TLS, DTLS, or TLS/DTLS.

- Mark all DTLS-OK=Y rows to “TLS/DTLS” and all DTLS-OK=N to “TLS”. [2]

- Add “TLS/DTLS” column to the TLS ExtensionType Values registry and mark the connection_id extension as “DTLS" and all others as “TLS/DTLS".

Selection:

While option 3 is the most work it does kind of future proof the registries and would make the columns the same in the parameter and extensions registry groupings.

spt

[0] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
[2] Most of the DTLS-OK=N are deprecated cipher suites, but a couple of Exporter Labels are also marked as DTLS-OK=N.

> On Jun 20, 2019, at 21:46, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 26 Jun 2019 17:35:03 +0000

Something should be done, I don't have a strong preference for 2 or 3.  Having this info back then might have prevented Heartbleed.

---

From: Nick Harper <[email-masked]>
Date: Wed, 26 Jun 2019 11:54:55 -0700

I have a slight preference for 3.

On Wed, Jun 26, 2019 at 10:35 AM Salz, Rich <[email-masked]> wrote:

> Something should be done, I don't have a strong preference for 2 or 3.
> Having this info back then might have prevented Heartbleed.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Jun 2019 13:44:12 -0700

I think we need to do 3, especially with QUIC. Are we sure they won't
want extensions?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 27 Jun 2019 11:27:12 +1000

On Thu, Jun 27, 2019, at 03:32, Sean Turner wrote:
> The IANA DEs (Designated Experts) think that the registry should 
> indicate that the connection_id  is DTLS-Only.  This is the first 
> extension defined that would need this marking.  Currently, there is no 
> “DTLS-Only” column in the TLS ExtensionType Values registry nor is 
> there a "DTLS-OK" column like there are in the TLS Parameter registries 
> [0].  Note none of the TLS extension registries [1] have a "DTLS-OK” 
> column.

Let's look at something less interesting than this, like the use_srtp extension.  The current conception of that is DTLS-Only, but it turns out that it makes a lot of sense to negotiate that in QUIC, which is essentially TLS and not DTLS.  It's fairly simple to update the IANA registry when defining the new usage, but that can be done by adding a reference to a new document.

So for me the question is how much detail you need to capture in the registries as opposed to the spec.  The spec can capture a ton of nuance that the registry can't.  We won't ever manage to tabulate all the properties of registered values; so the question is whether there is some value in having that information available in this form.  I can't see that here.

Worse, if we say DTLS-OK=N for an extension, is that a license to kill a connection if a client offers that extension?  The same applies to any codepoint that might be so restricted.  That would prevent the use of use_srtp in QUIC, so we'd need a new codepoint if we wanted the same semantics.  That's a strictly worse situation than where we are today.

I strongly prefer doing nothing.

p.s.,

I went through the registries and the ones listed below with an X don't - in my opinion - need the DTLS-OK column.  In all of these - except as noted - all registered values have a Y as far as I can see.  So my view is that only the cipher suites need the column, and only for historical reasons that no longer apply to any suite we might newly define.

X    TLS ClientCertificateType Identifiers
    TLS Cipher Suites
X    TLS ContentType
X    TLS Alerts
X    TLS HandshakeType - why is EOED marked DTLS-OK when it is prohibited?
X    TLS Supported Groups
X    TLS EC Point Formats
X    TLS EC Curve Types
X    TLS Supplemental Data Formats (SupplementalDataType)
X    TLS UserMappingType Values
X    TLS SignatureAlgorithm
X    TLS HashAlgorithm
?    TLS Exporter Labels - this uses the DTLS-OK=N heavily, but that is because the usage for those exporters is in TLS and never DTLS, there is no inherent reason for the column to be present
X    TLS Authorization Data Formats
X    TLS Heartbeat Message Types
X    TLS Heartbeat Modes
N/A    TLS SignatureScheme - no column
N/A    TLS PskKeyExchangeMode

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jun 2019 01:32:56 +0000

>    Let's look at something less interesting than this, like the use_srtp extension.

No, let's stick with the interesting case before us because, well, it shows a problem.  We have a problem and lack of clarity in the registries, which can even be misleading. Yes the spec is definitive, and maybe a prolog in each TLS registry should state that.  But implementors and reviewers sometimes need a checklist.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 27 Jun 2019 12:26:42 +1000

On Thu, Jun 27, 2019, at 11:33, Salz, Rich wrote:
> No, let's stick with the interesting case before us because, well, it 
> shows a problem.  We have a problem and lack of clarity in the 
> registries, which can even be misleading. Yes the spec is definitive, 
> and maybe a prolog in each TLS registry should state that.  But 
> implementors and reviewers sometimes need a checklist.

Sure, but in this case, there is a potential for collateral.  Do you think that is not an important consideration?

---

From: Ira McDonald <[email-masked]>
Date: Thu, 27 Jun 2019 06:44:20 -0400

Hi,

I strongly prefer option 3.  The future-proofing and avoidance of a
proliferation of new columns in the IANA registries is paramount.
The points about QUIC highlight the near-term need to clean up
this this issue.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Jun 26, 2019 at 1:32 PM Sean Turner <[email-masked]> wrote:

> While these IANA points are minor, what is being considered here affects
> all TLS registries so please let us know what you think about the proposal
> for the following issue:
>
>
> Issue:
>
> The IANA DEs (Designated Experts) think that the registry should indicate
> that the connection_id  is DTLS-Only.  This is the first extension defined
> that would need this marking.  Currently, there is no “DTLS-Only” column in
> the TLS ExtensionType Values registry nor is there a "DTLS-OK" column like
> there are in the TLS Parameter registries [0].  Note none of the TLS
> extension registries [1] have a "DTLS-OK” column.
>
>
> - Add “TLS/DTLS” column to the TLS ExtensionType Values registry and mark
> the connection_id extension as “DTLS" and all others as “TLS/DTLS".
>
>
> Selection:
>
> While option 3 is the most work it does kind of future proof the
> registries and would make the columns the same in the parameter and
> extensions registry groupings.
>
>
> spt
>
> [1]
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
> [2] Most of the DTLS-OK=N are deprecated cipher suites, but a couple of
> Exporter Labels are also marked as DTLS-OK=N.
>
> > During the DE’s review of the assignments for
> draft-ietf-tls-dtls-connection-id, they requested a new “DTLS Only” column
> be added to the TLS ExtensionType Values registry. This connection_id would
> be the only “Y” and all others there now would be “N”.
> >
> > The chairs also noted that the IANA considerations in
> draft-ietf-tls-dtls-connection-id needs to specify values for all the
> columns for connection_id in the TLS ExtensionType Values registry and
> tls12_cid in the TLS ContentType registry.  Here are the proposed values:
> >
> > connection_id

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jun 2019 12:13:25 +0000

>    Sure, but in this case, there is a potential for collateral.  Do you think that is not an important consideration?
  
A consideration yes.  An important one no.