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

Eric Rescorla <ekr@rtfm.com> Sat, 04 June 2016 16:49 UTC

Return-Path: <ekr@rtfm.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 E94B612D53B for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 09:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 flY53-TAWqYS for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 09:49:22 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 ED6D612D522 for <tls@ietf.org>; Sat, 4 Jun 2016 09:49:21 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id o16so107048478ywd.2 for <tls@ietf.org>; Sat, 04 Jun 2016 09:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rq60+yvlEoqupn5CakM0nox0FM0XeJ08ysCmI9wTuOY=; b=vxSbqKDl+q9jlihUkVzjZ9kpZrSO9TSXtmTOVtMt4EX+aU/W9dyuO4cit9aRKFUewE 0AJQXQUxkEt4+MUrHPbOIMPRQkiGJnj/BWGPVz1sMJi3cNK/XWfU02HxNCSUCwhUpXoF xH2pM3RcZBlLg7qO3gUr0x/O5mbyTfwencE4PGTz4TmRW5Uav8qtw0UqrYfpWTPqGbRH vHV1m1r2mHGramUD4oq22Gii6t8g9Xku+BQ5a4oi/Newj4VgjCPYxMhCzdOj8bI2uH/b 7RzxlfEmOdKlU590QsVy39pSBPu5UYzx40/gX7XTk4NJinETwIgwPqVksW6ZGqo7EE9H y5Dw==
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=Rq60+yvlEoqupn5CakM0nox0FM0XeJ08ysCmI9wTuOY=; b=RrXhvHfZcycadAgyGFGbvR16gwNMsj2OEnCLs419+JSUfvEgBc0HfvA6G+cOcSfjFV tjK3vn/tF6UCWt0a3pQ01Lbl01UDWdmO92Fqz5n1+FWaLsg3WpmMF5MC1OzU4LHYFqNd hKNX8wdvwZvOEqgAvL8yC0svK7PipudBkl/j88bLx8c4oI2hnDmCX7cn9DHgjr6uVAFz M8lN1ii0XL4aIVzznqvMDGOByNCraYG/q/a1e3wMItB0/F1/YE1BBcQfHc4FeIaNBsgc KmUEFEBqJRq8hXIWiVyVodEWtE54t/M++jWhbYxea/QH9FTGw0OsVCxZ8V1Lgl9nd4N6 U15A==
X-Gm-Message-State: ALyK8tIQ2u5M+dCHPM1N0AqGRrsNCqyI4mN5cqeYHrghLUrcnzeDj7dcUC6mA9F3Q6nK/EagclB9UHHTUIB+Pg==
X-Received: by 10.37.49.193 with SMTP id x184mr6191867ybx.57.1465058961128; Sat, 04 Jun 2016 09:49:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.230.76 with HTTP; Sat, 4 Jun 2016 09:48:41 -0700 (PDT)
In-Reply-To: <57530011.50905@gmail.com>
References: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com> <57530011.50905@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 4 Jun 2016 09:48:41 -0700
Message-ID: <CABcZeBNTFC=9hE4eSqqbj7eF5tRc+vKv7udEmXUjMk7b5gG3AQ@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a1148af18f468080534769e98
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6VxcAEMDENOghbgPFaAbrkUZNJI>
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 16:49:24 -0000

On Sat, Jun 4, 2016 at 9:21 AM, Yaron Sheffer <yaronf.ietf@gmail.com>; wrote:

> Hi EKR,
>
> This is confusing: on the one hand you encourage clients to use multiple
> tickets when available, "to the extent possible use a different one for
> each new connection", and on the other hand you say that a simple way to
> follow the Generation policy is to keep only the latest ticket, and then
> presumably to use it multiple times.
>

What I'm trying to make clear is that clients which don't open multiple
concurrent connections don't need to do anything fancy, but that clients
which do, should.


Can you please expand on the motivation here? Do we assume that a browser
> normally opens (say) 5 connections concurrently and we want each one to use
> fresh/separate key material?


It's not separate keying material. This is a question of linkability
between the connections.



> If so, maybe the client should indicate how much concurrency it plans to
> use?
>

Yes, we could do that


I think we would all be happier if the security proofs hold even if clients
> use the same ticket again and again.
>

To the best of my knowledge, the proofs already assume this, but perhaps
Thyla, Sam, or Cas, can weigh in.

-Ekr



> Thanks,
>         Yaron
>
>
> On 04/06/16 18:51, Eric Rescorla 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
>>
>>