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

Kyle Rose <krose@krose.org> Sat, 04 June 2016 19:36 UTC

Return-Path: <krose@krose.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1232812D5BB for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 12:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5E1jpgmYeGl for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 12:36:46 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F02012D1BD for <tls@ietf.org>; Sat, 4 Jun 2016 12:36:46 -0700 (PDT)
Received: by mail-qg0-x22d.google.com with SMTP id p34so26373026qgp.1 for <tls@ietf.org>; Sat, 04 Jun 2016 12:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; 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; d=1e100.net; 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 10.140.94.165 with SMTP id g34mr2056983qge.81.1465069005470; Sat, 04 Jun 2016 12:36:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.96.130 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: <CABcZeBO_QZ85FkQ9vVX13=F1PNf7G+sTJDCTWD_edeHfEy+xiA@mail.gmail.com>
References: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com> <CAF8qwaBe5s74qWrA5+NSpc18Z631a7pYdrx6H=m=nTpQheHcUw@mail.gmail.com> <CABcZeBOE5md1kz2NcnobgvLXEC1yMH=0U_-_Y+pN2NZ=C0xH=w@mail.gmail.com> <CAJU8_nWPOa+QocTRur01qBwaRL60X3S2wztAQFxxSUGLupKD2g@mail.gmail.com> <CABcZeBO_QZ85FkQ9vVX13=F1PNf7G+sTJDCTWD_edeHfEy+xiA@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Sat, 4 Jun 2016 15:36:44 -0400
Message-ID: <CAJU8_nVOMQTBTCP=SFuN3VqHp9vmry+WmEebKUZhMgCXUv2C8Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a113a4222a48f19053478f551
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wBKaDxnhcGGzYD_i5dqh-9D_vSA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR #493: Multiple concurrent tickets
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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.

Kyle