Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Viktor Dukhovni <> Wed, 20 November 2019 03:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E840120236 for <>; Tue, 19 Nov 2019 19:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kf8-o6748cg6 for <>; Tue, 19 Nov 2019 19:48:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 686AB120232 for <>; Tue, 19 Nov 2019 19:48:13 -0800 (PST)
Received: by (Postfix, from userid 1001) id A03EB331A79; Tue, 19 Nov 2019 22:48:12 -0500 (EST)
Date: Tue, 19 Nov 2019 22:48:12 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 03:48:15 -0000

On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote:

> >     - 0x01-0xfe => client wants single-use tickets:
> >         + send up to that many tickets on full handshake,
> >         + however, generally send just 1 ticket on resumption, or when
> >           replacing tickets during long-lived connections.  This helps to
> >           reduce chronic ticket "oversupply".
> Having a recommendation to generally just send one ticket

You left out the key qualification: "on resumption".  Now perhaps
that strategy is only needed in the *absence* of any signal from
the client, and with the extension the onus is perhaps on the client
to send "1" once it has enough tickets, in which case the server
does not need to apply the heuristic that helps it to avoid chronic
ticket oversupply.  In which case, the "generally send just 1" can
be left out, it is a side comment, not essential to the overall

Somebody should try to avoid ending up with N new tickets after
every connection, but in could well be the client.

> doesn't address the motivating use case for the document, which is Happy
> Eyeballs (connection racing). Having multiple tickets is required in a steady
> state, so we shouldn't recommend against that.
> Any client that wants to only do the reuse case can just not use this extension.

No, the extension is *very* useful to such clients, to signal to the server
that that's what they want to do, so that the server then only issues new
tickets when necessary.