Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 01 October 2019 14:56 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965E61208DF for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 07:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhwnPNn2dp_S for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 07:56:01 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D41D120842 for <tls@ietf.org>; Tue, 1 Oct 2019 07:56:01 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 80AAC2A5ABE; Tue, 1 Oct 2019 10:56:00 -0400 (EDT)
Date: Tue, 1 Oct 2019 10:56:00 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20191001145600.GU21772@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <156962803631.24993.3421537129925787732@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TXOSOMJqtQvmwY22_46amLs_TRQ>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 14:56:04 -0000

On Fri, Sep 27, 2019 at 04:47:16PM -0700, internet-drafts@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.