-
Notifications
You must be signed in to change notification settings - Fork 3
Proposal for Profile ID Registry #87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
29a060b
fd1aba8
3161243
0917ce2
f79f5af
bee5432
ca22f85
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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` | ||
|
|
@@ -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 | ||
|
|
||
|
|
@@ -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. | ||
|
|
||
| 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 | | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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."
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 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 | ||
|
|
||
|
|
||
There was a problem hiding this comment.
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.