On Fri, Sep 27, 2019 at 04:47:16PM -0700, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title : TLS Ticket Requests
> Authors : Tommy Pauly
> David Schinazi
> Christopher A. Wood
> Filename : draft-ietf-tls-ticketrequests-02.txt
>
> 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 may 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.
I've read the draft, it looks quite useful and reasonable. It would
be good to see this published.
I have one idea (implemented in OpenSSL 1.1.1 on the server side)
that may be worth mentioning in this context (and perhaps even the
draft):
- By default, OpenSSL TLS 1.3 servers only vend multiple (two)
tickets on full handshakes. Resumed sessions issue just one
ticket.
This avoids unbounded linear growth in the number of tickets vended
to a client that makes many resumed connections even after reaching
its peak connection concurrency.
When, instead, even resumed connections (which consume at most one
ticket) also receive more than one ticket, after N connections the
client has at least N as yet unused tickets, which is a waste in
steady state.
With the proposed extension a client that already has sufficiently
many tickets to handle peak concurrency can start sending 1 as its
requested ticket count if it does not reuse tickets, and else 0 if
it is reusing tikets and has all the tickets it needs for now.
Sending 1 on resumption when enough tickets are at hand helps clients
avoid receiving useless tickets from servers that don't implement
the OpenSSL strategy. Sending 0 helps even with servers that use
the OpenSSL strategy to avoid sending pointless tickets to clients
that do reuse tickets and don't presently need more.
In OpenSSL, with 2 default tickets vended per full handshake, and
a client that implements single-use tickets, it takes N initial
full handshakes to reach steady-state with N concurrent resumable
sessions, after which time each resumption gets a new ticket for
the next resumption.
With the proposed extension, I'd raise the number of tickets vended
on a full handshake to the smaller of say 5 and the client's requested
count, which make it possible to prime N parallel tickets in N/4
previous full handshakes. I'd still (by default) cap the ticket
count vended in a resumed session at 1, but a hint from clients
that have enough and send a request for 0 new tickets would then
be helpful.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
