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

David Benjamin <> Sat, 04 June 2016 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CCD912D51F for <>; Sat, 4 Jun 2016 11:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, 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 TOk9O15RI-yk for <>; Sat, 4 Jun 2016 11:10:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C609512D595 for <>; Sat, 4 Jun 2016 11:10:20 -0700 (PDT)
Received: by with SMTP id p194so109236397iod.1 for <>; Sat, 04 Jun 2016 11:10:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YeAFJ//lGLbF+orcdsqqZeUrYHRXNq3lZceNpw4s5o4=; b=IHkEMiA7CtoJ4TUJO2F/yGB5uG5N+IGm/5jq8A9+liHQNDRpbShK7VZVfxV41OEUjj kcvwTXBeueLLeijMF7rO20BXQFY+oCivR4bTZakKLGHRrHSpP0U1sfHqkK9sE+bUoqkw h0LAP0RlAmvzy5uhiBLkC2obKXj+mmS/aIXYQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YeAFJ//lGLbF+orcdsqqZeUrYHRXNq3lZceNpw4s5o4=; b=V8R2UmJEvRR6sY0keqVJqrEMYiR6l1YSm7pL05QuM3JfZD3N0hD0DZoggBTciDeSa9 OJ9VPlLH07xSVrriKD90y7dV1nsWIqpZaJebvbRWM9UKdKtL0Hj7hOcS+1O6sRrBeR7+ QfDSOxuyNJ9x6IhbOVc8qYdWPCKw1NmbyQY8L8QdXLyKQEIAkwekYer9Yw2/SWveRVLT NRyTYUA4e5N2zdD277SpaYxvFDAiRkr/ERsrGtl5e8aTjIv6sgZB82GAXV5/X6bgLdMg nxT1pvXPmAqsdUY2Lavw8aiSHugVONfFGoAL7/E1B0cQpqZR0ahCf5BPA0tRXZ/CS7U0 nnxA==
X-Gm-Message-State: ALyK8tKgrwEvF+Zzha2KWtlFZg/70UDJ4MZg5dA+7ywUNwBkBj1CwucMp+tr0ko9M1C224JS0zqmF2bxmsgN/AEK
X-Received: by with SMTP id b16mr13329958ioa.6.1465063819843; Sat, 04 Jun 2016 11:10:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Sat, 04 Jun 2016 18:10:09 +0000
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a1144180e8e919f053477c06b
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:10:24 -0000

Wouldn't the server be required to handle such a case anyway? If it's doing
post-handshake auth, it wants to do something reactive, such as based on
HTTP request or so. But that means I may have not hit an auth'd URL, saved
the session, resumed it, and then hit an auth'd URL. Or perhaps I have two
connections, one of which happens to hit auth'd URLs and the other happens
to hit unauth'd URLs. There's no ordering between the two sets of sessions,
so the unauth'd one may win.

That means servers must already allow for resuming an unauth'd session,
hitting a auth'd URL, and sending a fresh post-handshake
CertificateRequest. If anything, I wouldn't want to encourage servers to
assume they can make assumptions here. (I have seen some sites make strong
assumptions of this sort, and they've been sufficiently strong that they're
unsupportable. It's basically incompatible with having any parallel
connections at all.)

Incidentally, Chrome will never offer or store sessions on renegotiation,
the exact opposite here, and no one seems to have noticed.


On Sat, Jun 4, 2016 at 1:16 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).
> 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.
> -Ekr
> On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin <>;
> wrote:
>> 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