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, 01 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.
- [TLS] I-D Action: draft-ietf-tls-ticketrequests-0… internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Jeremy Harris
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Nico Williams
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Rob Sayre
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Rob Sayre
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Robert Relyea
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Christopher Wood
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Daniel Migault
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Martin Thomson
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Martin Thomson
- Re: [TLS] I-D Action: draft-ietf-tls-ticketreques… Viktor Dukhovni