Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 22 additions & 16 deletions draft-ietf-tls-ctls.md
Original file line number Diff line number Diff line change
Expand Up @@ -205,6 +205,10 @@ reserved value is used (including the default value), other keys MUST NOT appear
in the template, and a client MUST NOT accept the template unless it recognizes
the ID.

This specification adds one profile to the IANA maintained "cTLS Profile IDs"
registry, see {{reserved-profiles}}. The "Base cTLS 1.3-only" profile uses
default settings for everything except the TLS version.

In JSON, the profile ID is represented as a hexadecimal-encoded string.

#### `version`
Expand Down Expand Up @@ -754,7 +758,7 @@ attacker could be using a forged template to impersonate the other party.
This should not impact any ordinary use of TLS, including Early Data (which
is secured by the previously completed handshake).

# IANA Considerations
# IANA Considerations {#iana}

## Adding a ContentType

Expand Down Expand Up @@ -808,27 +812,29 @@ This document requests that IANA change the name of entry 6 in the TLS
HandshakeType Registry from "hello_retry_request_RESERVED" to
"hello_retry_request", and set its Reference field to this document.

## Reserved profiles
## cTLS Profile ID Registry {#reserved-profiles}

This document requests that IANA open a new registry entitled "Well-known
cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page,
This document requests that IANA open a new registry entitled
"cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page,
with the following columns:

* ID value: A sequence of 1-4 octets.
* Template: A JSON object.
* Note: An explanation or reference.
* Value: A sequence of 1-4 octets.
* Name: Name of the profile.
* Description: Short description of the profile.
* Reference: Reference to the document or documents that specify the profile.

The ID values of length 1 are subject to a "RFC Required" registry
policy. Values of length 2 are subject to an "Specification Required" policy.
Values of length 3 and 4 are subject to a "Private Use" policy.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the utility of a "private use" range here. All IDs longer than 4 bytes are already basically "private use". It would seem more sensible to me to shorten Value to 1-2 octets, or possibly to mark lengths 3 and 4 as Reserved.


The ID values of length 1 are subject to a "Standards Action" registry
policy. Values of length 2 are subject to an "RFC Required" policy. Values
of length 3 and 4 are subject to a "First Come First Served" policy. Values
longer than 4 octets are not subject to registration and MUST NOT appear
in this registry.
The initial registry content is:

The initial registry contents are:
| Value | Name | Description | Reference |
|:=========:|:===========:|:==========================:|:=======:|
| `[0x00]` | base-cTLS | Base cTLS 1.3-only Profile | RFCXXXX |

| ID value | Template | Note |
|:=========:|:==================:|:=============:|
| `[0x00]` | `{"version": 772}` | cTLS 1.3-only |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change deletes the template, so there's no longer anything that explains the meaning of ID [0x00].

Is there a reason not to include the full template in the registry? Adding a layer of indirection is confusing to me, especially for FCFS registrations (length > 2). Under this policy, these registrations could have a Reference that points to any "document", leading to interoperability challenges if that document changes or disappears.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The profile id does more than just indicating a version number. Hence, a reader will always have to look at the specification that defines what the template does. Hence, I believe it is fine to have a reference to the spec included for the profile id.

If there is the worry that the referenced specification "disappears" then we should add that we want a stable reference there.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The profile id does more than just indicating a version number. Hence, a reader will always have to look at the specification that defines what the template does.

The "Template" field in the current version provides the exact, entire template indicated by this profile ID. (It just so happens that profile ID zero corresponds to a template that uses default settings for everything except the TLS version.) An implementor does not need to read the reference; they just need to copy+paste the registry into their source code.

I think this is a good arrangement, especially if we don't expect many registrations of very large templates. (Registrations containing certificates would be ugly, but it's not clear why anyone would want to do that.)

However, even if we decide to leave the template out of the registry, I maintain that this change doesn't work, because the template corresponding to ID zero is not specified in this document.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added text to the draft to get this point accross: "profile ID zero corresponds to a template that uses default settings for everything except the TLS version."

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with expanding "Note" to "Description" and adding Change Controller and Reference, but I don't understand why we shouldn't include the template. Registered IDs are exactly equivalent to a specific template, which is easily represented here in JSON. Without it, we are asking implementors to go read the reference and look for the template, so they can copy-paste it from there. I think this would result in far less interoperability for registered IDs. (Servers can only use registered IDs if they know that 100% of their client pool supports that ID, so easy implementation of new IDs is very important for them to be useful.)

In fact, an implementor using that strategy would fail here, because the 0x00 template is not provided anywhere in this document. The implementor has to find the description in the text and interpret it to mean {"version": 772}.

Additionally, I have some concerns about the "name" column. This column seems to be intended for use as some kind of unique identifier, but its format (e.g., allowed characters) is not defined.

> RFC EDITOR: Please replace the value XXXX to the RFC number assigned for
this document.

--- back

Expand Down