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

David Benjamin <davidben@chromium.org> Sat, 04 June 2016 17:06 UTC

Return-Path: <davidben@google.com>
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 9859012D5B3 for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 10:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level:
X-Spam-Status: No, score=-3.425 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 nOp8ZOfYCFbB for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 10:06:54 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 236E712D59C for <tls@ietf.org>; Sat, 4 Jun 2016 10:06:50 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id i65so6960003ith.1 for <tls@ietf.org>; Sat, 04 Jun 2016 10:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IY5RC2EV1JsKA0JNG9OFn7Gr0059nVirrkLTxl7jEUg=; b=mw4h35lcYI/IuER8tj3BmLwmK7kIHrx9DHpQt6angL0mX21owDyBjMsfmEfHssdNHb blFZAevy/a+amh9DOQHD70Tri6mrOuZ+PZuUEP0m+Q0RUOtQX7DkulAViy24+5h+kYYs C0u5IKWSuhJ6mw2sROIZODdosbP0Eoa317fLY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IY5RC2EV1JsKA0JNG9OFn7Gr0059nVirrkLTxl7jEUg=; b=RlMbnFdjx9qNGd7bwJP/SaDl9Bq8bGHO3hgVmBZG5W+7uHFwHHkQnENZyTd6YZDmDO HLJs26URdSh8jwJ3RbFtGiW/tTF4pH/WRHyZl0Z9IK2qxHMfIpA/m+BLduRL3rXGAw9N dHzOuab/LMY9Dsap75r9RZLVO574vmbzTHCfSnz8bqBFiP3ZPQhIuyL06v5bUfQsSb8i jh1rM8RmV8pqcL70F2R+wPBji3wIW0cacD57mnU/gwFw+eCmZW0IE630Srrgrs/wxu05 tbeGyoyuaks36xNah0qRmXI4a9XECRND9h9bNtthCQd4hKSQkmuue8qT3QLYRRZ9o2yR +sYg==
X-Gm-Message-State: ALyK8tLWk25dRSdmB7Fn5IUM/CD30Mr0CUrZMNbUemZaPdpfdgLG+g9iZWVKzdpm53t7FermSUq8Z/p0Qg/ggUfD
X-Received: by 10.36.227.131 with SMTP id d125mr7214942ith.18.1465060009209; Sat, 04 Jun 2016 10:06:49 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com>
In-Reply-To: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 04 Jun 2016 17:06:38 +0000
Message-ID: <CAF8qwaBe5s74qWrA5+NSpc18Z631a7pYdrx6H=m=nTpQheHcUw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c1116206ccbb0053476ddcf
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3KdivQKjDcXwnL8f96I5pkQJnHc>
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 17:06:56 -0000

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 <ekr@rtfm.com>; wrote:

> https://github.com/tlswg/tls13-spec/pull/493
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>