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

Eric Rescorla <> Sat, 04 June 2016 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B68712D52E for <>; Sat, 4 Jun 2016 10:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jhKroF5Qa8-Y for <>; Sat, 4 Jun 2016 10:16:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B86E12D522 for <>; Sat, 4 Jun 2016 10:16:03 -0700 (PDT)
Received: by with SMTP id o16so107400665ywd.2 for <>; Sat, 04 Jun 2016 10:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G1A1YgVU7skr3cyC0YaL3HEl0B8GgkIfM4vrZR/WqTw=; b=U3STM2y87WG3GOkvr5BJQpKM4qiu3tQCApOT5yBHHAtLlIdHODDE1v03zcAZu/pYpp /xhrV82HxKQpi44HhEIeelL6nPMiP4NuOPm1tnHyVToyu0lEQjJSD3nFQCWea5as13Kg kREAdo5mSDiFREFd/aBeC1Oo6wm5Bdn/589z8PbLglY51PKxrCBazCfkfuz6/sECDuAj HKynLUWgG8EN80IOfHWnXl0eI8f20qZRurw34fFVGPGf4G/kqvQwIcUwwgaE9Oq7j2qz qXM3uEh0Dp9+pdg76YsLuJbbG0AoWAmB0Wh2hK8dcQJcx8sKSsSFqRuzrBOIniXXU1+s AQuQ==
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=G1A1YgVU7skr3cyC0YaL3HEl0B8GgkIfM4vrZR/WqTw=; b=ktkolL7HbdfR/ajkzGD+DzrcyfHlED19TVXkqrCGnaxdvzNf1X2OcjcIAbjwRVi9Ah ViTnVLGXyo/ijsxfYMdIjXLpuQcCq/FyfWP1GmtIJ3VMOjBoQmgvfKiptY9uMBcY1rcx o5ipPbezxEtFwNd5RkfwKi58SW9EYueJhzUDV+wmtMXjw1UMNl0sOOhnRy7iOeMGcL49 2qoKyImHJkbqM5KJR7ZT7gamHh1EqImyTuCxEhPLJAORRjYt22fqpUzyS1YUjFqzCHBZ HNwgE3/9RgYwInhSZMeREVaOcxL2YdmvbcqFj3uYNOqgXBmhqqGqWkjP3URCo0fGh3t+ 5xTA==
X-Gm-Message-State: ALyK8tJZm+mnQ0CH7cnJBxqrO0iYvUDb8AmYrRICiKs2TXvQiitsTk/Ty7ckwmOmVOZZuKZqdpaLX98+cmprbg==
X-Received: by with SMTP id z142mr6297107ywz.322.1465060562563; Sat, 04 Jun 2016 10:16:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 4 Jun 2016 10:15:23 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Sat, 4 Jun 2016 10:15:23 -0700
Message-ID: <>
To: David Benjamin <>
Content-Type: multipart/alternative; boundary=001a11422568682331053476fece
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 17:16:05 -0000

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).

Anyway, I could live without doing this now (part of why I added ticket
extensions is to let us make these decisions later), if nobody else thinks
it's that valuable. I *do* think it's important that we make sure that
analysis supports multiple tickets pointing to the same underlying RMS.


On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin <>;

> I'm not sure I follow why the additional "generation" machinery is
> necessary.
> What do we gain from having the server to tell us to discard a ticket
> beyond what the ticket lifetime already gives? This doesn't seem an
> effective way to discard key material since, unlike the ticket lifetime, we
> need a live connection to the server at the time. Beyond that, if a client
> uses a ticket the server no longer likes, we'll just fall back to a full
> handshake. That seems fine.
> I would favor simply saying the client SHOULD prefer to use more recent
> tickets over earlier ones (since that's probably a good idea) and that
> clients which expect to open multiple concurrent connections SHOULD retain
> a window of several one-use tickets. We can always add this generation
> thing back in later as a TicketExtension if we change our minds.
> Am I missing something?
> David
> On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla <>; wrote:
>> Currently the server can send multiple tickets but we don't say anything
>> about the semantics.
>> So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants
>> to initiate m < n connections, should he use:
>> - only T_n
>> - T_1...T_m
>> - T_n, T_n-1, ... T_n-m+1
>> The intuition I have had is that we want the third option (latest wins,
>> but allow multiples for linkability) but the spec doesn't say and there
>> aren't any semantics that tell you, so I think we want some way for the
>> server to say "these group of tickets are all co-valid".
>> I've just created PR#493, which provides an explicit mechanism for this,
>> "ticket generations". Tickets with the same generation M are co-valid and a
>> ticket with generation N expires all tickets with generation M < N. The
>> nice thing about this encoding is that a client can implement the old "one
>> ticket at a time" behavior by just ignoring the generation and taking the
>> last ticket.
>> I wanted to call out to cryptographers/analysts that this formalizes the
>> existing practice (going back to RFC 5077) of having multiple ticket values
>> tied to the same basic secret (though less so with 1.3 because tickets
>> issued on connection N+1 don't have the same RMS as those on connection N).
>> If there is a problem with this, that would be good to know.
>> Barring major objections, I'll merge this Thursday.
>> -Ekr
>> _______________________________________________
>> TLS mailing list