Re: [TLS] AD evaluation of draft-ietf-tls-ticketrequests-05

Christopher Wood <> Thu, 05 November 2020 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ADCD3A110D; Thu, 5 Nov 2020 05:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=vdXxmGAz; dkim=pass (2048-bit key) header.b=odc3SXsm
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ottKFa48o_Tm; Thu, 5 Nov 2020 05:38:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6EF13A1113; Thu, 5 Nov 2020 05:38:43 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 081FD5C01BF; Thu, 5 Nov 2020 08:38:43 -0500 (EST)
Received: from imap4 ([]) by compute4.internal (MEProxy); Thu, 05 Nov 2020 08:38:43 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=bHYUr7anyA1jCMNgIaPXS8jud5eB 1J/HdnYnvRbwB/g=; b=vdXxmGAz+stWIP+kCLiCQLxNklcVlrUe4dWYsWSA2p3/ UMRoTGqDlJzVwHqVfU5aHWDLgZRlY3glnc6iyf/X+rXWo0TOo2/dYkzbmjiQ98/R 1JC+3flmKVM1EYMDY1WXDZ2lFYN1WMxrGHjuOG9TTGiJOzWyGDWj8POVJBADjqtp a7xwY12wWWwLqGp99GF5dzSSdqJwZ3H97LnBkA8YBhV8Y7nsQ/5KqY397cz10ZJI vn8ruoRJQ8k1bEtt/Tx7Vx5X7MMHPfN7X+k1gsKvTqA5DAyhrlxwvUp1t0bUOM4a RJ7JGrB1KHk1MzdyHhGpSaF6NDfnPILFvdhmT+74iQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bHYUr7 anyA1jCMNgIaPXS8jud5eB1J/HdnYnvRbwB/g=; b=odc3SXsmSHga20sN8xElhW X+yAdR+VCYt67LL9MYs/I7x+QT1vXC1UrvQQSECFIKzUZ3/fda3ljp9N/dRf/GnR zSe8oVbyYMsbggRT8ZZ01ZNz2ZcgtkL4UlO2Yp0T7e9uP7Q2jz06vSpiUa2dzjpU Wt7jv7aPv8TdwW37U8JsF2rLPCt6EKargggaU9zYj9XHX2UQ1NRdhmzPTb3Y+Sm5 q64KeNzNjN53e/djh1yYWrqGL7zmX8X52PcLoTotJ0KEBvINSvSkELSuaLaa+dng YSJTB0JTYQzQ1s1YGxbZENJT0gQ4sJ+RmJTTx4CzhmKrA3fGoqeab6PY/6RgEQ9w ==
X-ME-Sender: <xms:YgCkX1JuSXtOxnwSyDOz_zY5WnfQh7P-Z6C9b4RXSGFJGS0m6bfHuw> <xme:YgCkXxLB747QymH9PyxWP4fSoEs9RiiCAmmuaS4Kpk8AjSd9lNagKdtLF64_BDRZ6 KY4Sbz8-woOQlQIV0Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtjedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepveekgedtgfdtjefhteeifeejhfdtgfdufedufeeljeeu vdejtdfhvefgvefgvedtnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhi nhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:YgCkX9u4g9OiJBBwVwSJQImAR2GVnORFkr6CUNLgGTuW0CBQdVh_1w> <xmx:YgCkX2bj8f_6TJUNNMNMzuAUyGfBbe-eKWtGJNXgpjaZ7UJUVA7PnQ> <xmx:YgCkX8Y6l54nIjV_4bTtsUyzDO43boivaPGXMVTWh4hSiDdXw9EOow> <xmx:YwCkX1D2vvjOhAzfvko0jF4qFodeMgyDsKcB-6cB43H0gSIcz-XueA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7F94A3C00A1; Thu, 5 Nov 2020 08:38:42 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-565-g5179928-fm-20201104.001-g5179928e
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Thu, 05 Nov 2020 05:38:22 -0800
From: "Christopher Wood" <>
To: "Benjamin Kaduk" <>,
Cc: "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] AD evaluation of draft-ietf-tls-ticketrequests-05
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: Thu, 05 Nov 2020 13:38:46 -0000

Thanks for the review, Ben! We addressed most of your comments here:

Please see inline below for followup responses specific points. If there are no objections, we'll spin a new version of the document when the submission system opens.

On Wed, Oct 28, 2020, at 3:27 PM, Benjamin Kaduk wrote:
> Section 2
>    *  Connection priming: In some systems, connections can be primed or
>       bootstrapped by a centralized service or daemon for faster
>       connection establishment.  Requesting tickets on demand allows
>       such services to vend tickets to clients to use for accelerated
>       handshakes with early data.  (Note that if early data is not
>       needed by these connections, this method SHOULD NOT be used.
>       Fresh handshakes SHOULD be performed instead.)
> This doesn't seem to paint a very clear picture of the use case.  It
> doesn't even seem to be clear about whether the "centralized service or
> daemon" is a helper on the TLS client or server side!
> I also want to check my understanding here, in that the recommendation
> for only doing this when early data is needed is due to the fact that
> you need to have an initial handshake with which to negotiate the
> ability to use early data in the subsequent handshake, and having the
> central service do a bunch of full handshakes just to get a ticket for
> use on a subsequent connection that does user early data is a lot of
> overhead, whereas if you don't need early data then you only do as many
> full handshakes as you need connections (vs 2x that number to get a
> ticket and then do early data) and get fully independent keys.  Since
> you have this central service the extra latency for a full handshake is
> irrelevant because you're priming connections in advance, not on-demand.

Describing this in more detail would lead to more text that probably just distracts from the document. To keep things simple, we just deleted this item, since there are plenty of motivating use cases already.

>    *  Less ticket waste: Currently, TLS servers use application-
>       specific, and often implementation-specific, logic to determine
>       how many tickets to issue.  By moving the burden of ticket count
>       to clients, servers do not generate wasteful tickets.  As an
>       example, clients might only request one ticket during resumption.
>       Moreover, as ticket generation might involve expensive
>       computation, e.g., public key cryptographic operations, avoiding
>       waste is desirable.
> (I assume we have a particular case in mind that does use public-key
> crypto when issuing a ticket, or we wouldn't have mentioned it.)

This just reflects the fact that ticket encryption is not required to be done with a symmetric key. Servers are free to choose any type of encryption. (We didn't change anything here.)

>    When a client presenting a previously obtained ticket finds that the
>    server nevertheless negotiates a fresh session, the client SHOULD
>    assume that any other tickets associated with the same session as the
>    presented ticket are also no longer valid for resumption.  This
> Unfortunately, RFC 8446 does not seem to be consistent about "session"
> (persists across multiple resumption handshakes) vs "connection" (a
> single handshake) terminology.  We may want to consider just discussing
> "full handshake" and "initial full handshake" instead of trying to use
> the "session" shorthand.

We converged on "connection" to avoid confusion, since that seems to be the more natural term. 

>    and the number requested.  Servers MAY send additional tickets, up to
>    the same limit, if the tickets that are originally sent are somehow
>    invalidated.
> (nit) pedantically, the server can send whatever tickets it likes
> whenever it likes.  The current "up to the same limit" looks a little
> bit like it's trying to restrict the server's behavior, so "typically
> using the same limit" might be better.
>    Servers MUST NOT send the "ticket_request" extension in ServerHello
>    or HelloRetryRequest messages.  A client MUST abort the connection
>    with an "illegal_parameter" alert if the "ticket_request" extension
>    is present in either of these messages.
> I note that we do have other messages (Certificate, CertificateRequest,
> NewSessionTicket itself, maybe soon ClientEncryptedExtensions) that can
> carry extensions, so in that sense it's strange to only explicitly
> prohibit these two.  That said, they are the two that would be most
> tempting to (inadvertently) put this extension in, so I don't
> particularly mind leaving it this way.

We clarified that it shouldn't be present in any handshake message.

Thanks again for the thorough and thoughtful review!