TLS Ticket Requests
draft-ietf-tls-ticketrequests-07

[Ballot comment]
Thanks for a very clear, well-written document.  Just one very tiny comment:

— Section 1.1 —
Please use the exact BCP 14 boilerplate from RFC 8174 (this one is missing “BCP 14”).

[Ballot comment]
Thank you for the work put into this document. It is short and easy to understand.

I find that the contents of section 1 and of section 2 are quite duplicate.

In section 2, the use of capitalized word after a ":" looks weird to me but I am not a native English speaker.

I hope that this helps to improve the document,

Regards,

-éric

[Ballot comment]
Some places in this document use "reuse", others "re-use".  I'm not sure which one is right, but it should be consistent throughout.

In Section 3:

  A client starting a new connection SHOULD set new_session_count to
  the desired number of session tickets and resumption_count to 0.

Since it's only SHOULD, I'm curious about why an implementer might decide to do something other than this.

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

The IANA Functions Operator has completed its review of draft-ietf-tls-ticketrequests-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that upon approval of this document, there will be a single action to complete.

In the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page at

https://www.iana.org/assignments/tls-extensiontype-values/

a single new ExtensionType is to be registered:

Value: [ TBD-at-Registration ]
Extension Name: ticket_request
TLS 1.3: CH, EE
Recommended: Y
Reference: [ RFC-to-be ]

As this document requests registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required expert review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Note:  The action 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

The following Last Call announcement was sent out (ends 2020-12-03):

From: The IESG
To: IETF-Announce
CC: tls-chairs@ietf.org, draft-ietf-tls-ticketrequests@ietf.org, kaduk@mit.edu, sean@sn3rd.com, Sean Turner , tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TLS Ticket Requests) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS Ticket Requests'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  TLS session tickets enable stateless connection resumption for
  clients without server-side, per-client, state.  Servers vend an
  arbitrary number of session tickets to clients, at their discretion,
  upon connection establishment.  Clients store and use tickets when
  resuming future connections.  This document describes a mechanism by
  which clients can specify the desired number of tickets needed for
  future connections.  This extension aims to provide a means for
  servers to determine the number of tickets to generate in order to
  reduce ticket waste, while simultaneously priming clients for future
  connection attempts.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/



No IPR declarations have been submitted directly on this I-D.

# 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.

# 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.

# 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 draft 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.

*** DRAFT ***

# 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.  I will note that the draft has informational since it was an individual -00 and when it was adopted by the WG, but the IANA considerations also included marking the Recommended column as “Y” since its individual -00 version as well.  I caught this mismatch, “Y” in the Recommended column requires Standards Track according to RFC 8446, during my Shepherd review.  The version being submitted to the IESG indicates standards track.  I emailed the WG to ensure there were no objections to the swap, but received radio silence.  I interpreted this silence as acceptance that rationale to switch to Standards Track.  But, I will also note that typically the TLS WG does not stand on process so I never really expected any kind of response from the WG.

# Review and Consensus

*** TBD

I 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 complains about an outdated normative reference.  This draft makes reference to both RFC 5077 and 8446, 8446 obsoletes 5077, so please ignore this nit.

*** DRAFT ***

# 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.  I will note that the draft has informational since it was an individual -00 and when it was adopted by the WG, but the IANA considerations also included marking the Recommended column as “Y” since its individual -00 version as well.  I caught this mismatch, “Y” in the Recommended column requires Standards Track according to RFC 8446, during my Shepherd review.  The version being submitted to the IESG indicates standards track.  I emailed the WG to ensure there were no objections to the swap, but received radio silence.  I interpreted this silence as acceptance that rationale to switch to Standards Track.  But, I will also note that typically the TLS WG does not stand on process so I never really expected any kind of response from the WG.

# Review and Consensus

I would characterize the consensus as having been reached fairly quickly and being broad enough to publish.

This draft has been discussed on the mailing list and at IETF 103.  Because the draft is straightforward, clear, and short, there has not been a lot of list discussion about the draft.  In my opinion, this is not such a bad thing.  The WG should be able to adopt a simple idea, discuss it, and get the draft out the door.

No reviews done to date, and there is no real need for any kind of special reviews.

I have no specific concerns about this draft.

# Intellectual Property

** CONFIRMATIONS from Tommy and Chris.  Awaiting David.

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 complains about an outdated normative reference.  This draft makes reference to both RFC 5077 and 8446, 8446 obsoletes 5077, so please ignore this nit.