Re: [TLS] PR #493: Multiple concurrent tickets

Kyle Rose <> Sat, 04 June 2016 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB28712D5BB for <>; Sat, 4 Jun 2016 11:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id steHKP0Fc_Kq for <>; Sat, 4 Jun 2016 11:42:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07CE412D0A7 for <>; Sat, 4 Jun 2016 11:42:29 -0700 (PDT)
Received: by with SMTP id j96so16352188qge.0 for <>; Sat, 04 Jun 2016 11:42:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZU+KQ/CuL5IWBK3lBZD2AmIHr+8hUcshmX9Xgr5xaYY=; b=LDXbUd4Yu+BdXG/WVGnvgJo6GlGH+CNHqNAu6alvadYNOBDPrv9iZrhTr5bThfEG1g O3OLr0Fp/FgFwVVmHnf1CrQHe3gNWX0KVvvZC94ZSK/8ccpfaPcvTNpLtJ3I9G0Bkh7m F6r5dm1VWvameCkkNYoLrEo8vn5Gb0yARWHrw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZU+KQ/CuL5IWBK3lBZD2AmIHr+8hUcshmX9Xgr5xaYY=; b=LHi8w7m9gyzu/JqwoE/n4ZKfqwDMMCWc61tWF7c+UOK8o726UVUtZI4/qxF0PfmLSq F/YvqJKtx1Ic+Jy28NGGo923R9HxMqwY5ig3ZnYk7H6u0zu3MH7FnTZNW1X/jUY0GSn+ sMLF0lQ9Ux0An1I9VuGKUYx/nGRauHTbPf7R7ksGurc1pttxHDIyFnAscGzYi0kK+1jy ze6cOTY/XionpSjI7SRsCz/28cBo4NRyUu7Z9LnMnqhxgqjSNUzCFh9vzeU/TkPRIDmf NREBhiCkM0oTICfJ12QDMTuaV9q/yTI89ZCUG/kUaWy92iKA7HUISaeNp4tibUIJCkvm /2Vg==
X-Gm-Message-State: ALyK8tIX7lm3ytReMQnkomthKF54eFbcBDO1qsu2lN++tGM4/ugvS7Nlvprvledj+Iqp2eTEnQLAYTh1Yf6jvg==
X-Received: by with SMTP id v49mr8595286qge.27.1465065749044; Sat, 04 Jun 2016 11:42:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 4 Jun 2016 11:42:28 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:c8cf:f1a1:c70a:cfad]
In-Reply-To: <>
References: <> <> <>
From: Kyle Rose <>
Date: Sat, 4 Jun 2016 14:42:28 -0400
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a11c168588b75ef053478333a
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] PR #493: Multiple concurrent tickets
X-Mailman-Version: 2.1.17
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: Sat, 04 Jun 2016 18:42:33 -0000

On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla <>; wrote:

> I don't think it's principally about discarding keying material, but
> rather about allowing the server to attach state to a ticket and then have
> predictable behavior. Consider the obvious case of post-handshake client
> auth (which I know you hate) and a client which has tickets issue before
> and after the auth event. If it tries to use them both, that's going to be
> annoying (though I agree, not fatal).

I have several thoughts:

(1) In many cases, the client can handle this unilaterally. Are there
examples of this kind of ticket-relevant state change that the client would
not be aware of? When the client is aware of a state change (such as client
auth negotiation), it can purge any tickets received before the state

(2) If the ticket isn't encrypted data but is instead just an index into
full session state on the server, the ticket might actually still be valid
for state changes that occur after the ticket was handed out. I have no
idea how common this brand of session caching is likely to be, but I'm
guessing "not very".

(3) Tickets already allow the server to encode state: the proposal here
seems to be about revealing additional ticket semantics to the client. The
server could after all encode the generation in the (encrypted) ticket and
then use that to reject old tickets: this results in more full handshakes,
but it would eliminate weird behavior when clients use old tickets.

Correctness seems achievable either way, so I'm not sure a purge mechanism
(beyond expiration) is justified by this specific use case in isolation.
Are there other uses cases for which server-initiated purge of classes of
session tickets would be helpful?