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

Hubert Kario <> Mon, 21 January 2019 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D04BE130F88 for <>; Mon, 21 Jan 2019 07:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ieMbXnIbPiJA for <>; Mon, 21 Jan 2019 07:10:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 570A1130FCD for <>; Mon, 21 Jan 2019 07:10:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9169E757D6; Mon, 21 Jan 2019 15:10:05 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id D035E61090; Mon, 21 Jan 2019 15:10:04 +0000 (UTC)
From: Hubert Kario <>
To:, Tommy Pauly <>
Date: Mon, 21 Jan 2019 16:09:57 +0100
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1638868.PUVoOPF6UF"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Mon, 21 Jan 2019 15:10:05 +0000 (UTC)
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-00.txt
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: Mon, 21 Jan 2019 15:10:09 -0000

On Saturday, 19 January 2019 01:32:35 CET 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-00.txt
> 	Pages           : 6
> 	Date            : 2019-01-18

> There are also htmlized versions available at:

The security section probably should note that large server self-imposed limit 
could be used for Denial of Service.

"Servers MUST NOT send more than 255 tickets to clients."
across the whole connection or directly after Finished? For long-lived 
connections that may be problematic, especially when connected with multiple 
post handshake authentication exchanges...

What about ticket count after post handshake authentication? Should we allow 
the client to re-issue the extension in Certificate message?

Should handling of "0" in extension be special? As in, if client is asking for 
0 tickets (e.g. because it will not do resumption), "SHOULD" the server 
respect that and send no tickets? (while the min(srv_limit, 
clnt_request.count) will do that, I think it may be prudent to spell it out)

Is the extension negotiated every time when resuming the session, or should it 
be saved as part of session data by server? What if client starts advertising 
it, drops it or changes value in the next ClientHello that offers resumption?

I'm assuming that it cannot be changed by client in 2nd ClientHello when doing 
Hello Retry Request handshake. Shouldn't that be stated explicitly though?
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic