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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05

Network Working Group                                           T. Pauly
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                             D. Schinazi
Expires: 26 October 2020                                      Google LLC
                                                               C.A. Wood
                                                              Cloudflare
                                                           24 April 2020

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

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 October 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Pauly, et al.            Expires 26 October 2020                [Page 1]
Internet-Draft             TLS Ticket Requests                April 2020

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Ticket Requests . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Performance Considerations  . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As as described in [RFC8446], TLS servers vend clients an arbitrary
   number of session tickets at their own discretion in NewSessionTicket
   messages.  There are at least three limitations with this design.

   First, servers vend some (often hard-coded) number of tickets per
   connection.  Some server implementations return a different default
   number of tickets for session resumption than for the initial full
   handshake that created the session.  No static choice, whether fixed,
   or resumption-dependent is ideal for all situations.

   Second, clients do not have a way of expressing their desired number
   of tickets, which can impact future connection establishment.  For
   example, clients can open multiple TLS connections to the same server
   for HTTP, or race TLS connections across different network
   interfaces.  The latter is especially useful in transport systems
   that implement Happy Eyeballs [RFC8305].  Since clients control
   connection concurrency and resumption, a standard mechanism for
   requesting more than one ticket is desirable.

   Third, all tickets in the client's possession ultimately derive from
   some initial full handshake.  Especially when the client was
   initially authenticated with a client certificate, that session may