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.