Skip to main content

Shepherd writeup
draft-ietf-tls-ticketrequests

# Summary

Sean Turner is the Shepherd.
Ben Kaduk is the Area Director.

This document defines a TLS extension that clients can use to inform servers
about the desired number of tickets to generate in order to reduce ticket
waste, while simultaneously priming clients for future connection attempts.

The draft is intended for standards track.  The individual draft indicated
informational and the initial WG draft did as well. A "Y" in the Recommended
column requires standards track though. Changing the track to standards track
was confirmed on list; there were no objections.

# Review and Consensus

The draft had a fairly quiet existence until the -02 version, which was also
the version where the authors requested the chairs request WGLC. The WGLC and
two issue-specific consensus calls that followed were all fairly contentious. 
The WGLC and the two issue-specific consensus calls resulted in changes to the
draft: the count field was renamed new_session_count, a new counter called
resumption_count was added, text was added to address racing pre-conditions.
The addition of the second counter acknowledged that resumption is different
and can tolerate the complexity of the additional counter. What was not added
was text to address ticket reuse use cases; RFC 8446 indicates "clients SHOULD
NOT reuse a ticket for multiple connections". One of the issue-specific
consensus calls about this was about this point and there was no consensus to
add text to address this use case.

I would characterize the consensus as rough. I give it this characterization
because, I believe, that the same people that supported adopting the draft
support publishing the mechanism, but there are differences in how far the
mechanism should go in supporting ticket reuse. I, however, have no specific
concerns about this draft.

# Intellectual Property

I confirmed with each author that to their direct, personal knowledge of any
IPR related to this draft has already been disclosed, in conformance with BCPs
78 and 79.

# Other Points

IANA considerations are correct; it refers to all the appropriate columns for a
newly registered extension.

There are no downrefs.

IDNits has no complaints.
Back