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

Kyle Rose <> Sat, 04 June 2016 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1232812D5BB for <>; Sat, 4 Jun 2016 12:36:48 -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 U5E1jpgmYeGl for <>; Sat, 4 Jun 2016 12:36:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F02012D1BD for <>; Sat, 4 Jun 2016 12:36:46 -0700 (PDT)
Received: by with SMTP id p34so26373026qgp.1 for <>; Sat, 04 Jun 2016 12:36:46 -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=CHCR+NdZQRN5WVwU26EnjvOgWP+Et5ECPsmVC4xuD8A=; b=fePFl3K0awJ0gd37o4Z+CBGcdpcRt0l/E76Ih4rT1oYKeNwu/4opU1gj+Ft6vPjHvY peScpMYSBU6thYBl/qW2qy2k7/N3hr7BtCPRZNS79dN5tCGugGPLFT67kmURqbVkDFQz 2EIjH/40hrOHgcnMyEgBf9HGhJrO4kZoGoP28=
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=CHCR+NdZQRN5WVwU26EnjvOgWP+Et5ECPsmVC4xuD8A=; b=eDeIb9YbInWSwor8HX3XoMFAcSGbd2WdvnCxTmA9FFNUAv8HM7GJ+TWjrJM+x1hK/5 Yx/VlOIvOksjGp2Sn71J4BW91qL9ZoVnUQ8/DLJ6aahP1Ufteblwx3Fh0s4X29tMOQHl ui4tm4wl8ksBTZnTzfv/GeIWFli1p8kXEXUJYRrlAwVi8omPFjO+J+oG8TOv42EkXIXq LHoFq5NXlSSfWNBVXNHJ9uTfcnCVZPEe8LBaheDDW3HcJl+6wbTgAYCBmk+4GPGaiQGR 5d/N/nkPXGVUmUstDm858dm28e2jbhbj3ewbFYf55m0hT7VkKE4UVHITlEu25xtno5NO 3FQw==
X-Gm-Message-State: ALyK8tLM5x6N7yEiyw5bkaUtBDU4fpM4Pa1RykP5mMVS35vBpvL716XgcFVhqE9CEnDPuhzSTXOL+1DkS8DQdA==
X-Received: by with SMTP id g34mr2056983qge.81.1465069005470; Sat, 04 Jun 2016 12:36:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 4 Jun 2016 12:36:44 -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 15:36:44 -0400
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a113a4222a48f19053478f551
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 19:36:48 -0000

> (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
> change.

> Sure. HTTP-level authentication via a Web form.

Would that typically feed into the ticket state? I'm thinking of something
like Rails, which (at least when I worked with it) maintained its own
session state separately from TLS session state, and signaled via cookie or
Auth header.

> 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?
> Unexpected key changes.

Rotation of the ticket-encrypting key? This seems like a good argument for
it, because it's something that's likely to happen regularly, and maybe
even on a schedule, and almost certainly across all clients simultaneously
(meaning "load spike" if the clients aren't guided to the right behavior).

In general, I like the idea of having a way to purge state beyond simply
expiration; I wonder if generation is the right level of specificity, or if
it's too general and we should reopen the expiration time vs. issue
time+TTL discussion and allow purging by issue time. (I'm not actually
suggesting the latter.) But I also don't have a strong opinion about the
balance between complexity and performance benefit here.