TLS Server Identity Pinning with Tickets
draft-sheffer-tls-pinning-ticket-12

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-sheffer-tls-pinning-ticket-10. If any part of this review is inaccurate, please let us know.

QUESTION: Has the registration in the IANA Considerations section been sent to the expert review mailing list described in Section 17 of RFC 8447? If not, please forward this request to that list.

We understand that this document is requesting one registry action. If it's approved by the designated experts, we'll add the following entry to the TLS ExtensionType Values registry at https://www.iana.org/assignments/tls-extensiontype-values:

Value: TBD
Extension Name: ticket_pinning
TLS 1.3: CH, SH
Recommended: N
Reference: [RFC-to-be]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

draft-sheffer-tls-pinning-ticket has been presented for publication as an Independent Submission Experimental RFC.

The document describes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity across multiple sessions without requiring manual management actions.

The document was presented to the TLS WG at IETF-98 where a hum in the room indicated inadequate support to adopt the work (https://datatracker.ietf.org/doc/minutes-98-tls/). There was no record of comments about security issues or conflicts with other standards, just lack of energy to adopt the work in the WG. The responsible AD at the time declined to AD-sponsor the draft, so it was presented it at SecDispatch (IETF-100) and the discussion there resulted in the decision to take the draft to the ISE. (This history was checked briefly with Sean Turner and seems to be accurate.)

Reviews of the document were performed for the ISE by Jim Schaad and Yoav Nir and led to good discussions with the authors and a number of updates to the document.

Additionally, we worked through the fact that this is an Experimental document by adding Section 1.2 that describes the scope and objectives of the Experiment, and that sets out the authors' intentions to bring the work back to the IETF if the Experiment is a success.

The document makes a request for a code point allocation from the "TLS ExtensionType Values" registry (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml). The allocation policy for the registry is "Specification Required" and the ISE reviews of the document were performed by two of the three Designated Experts for the registry. It should be noted that there is no "Experimental" range in the registry and that "Specification Required" is consistent with an Experimental Independent Stream RFC. It appears to be the intention that the "Private Use" range can be used for experimentation, but the authors specifically request allocation from the regular range (so that transition to IETF work could be made possible in the future) setting the "recommended" indicator in the registry to "N" to show that this is not IETF consensus work.