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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 04 June 2016 16:21 UTC

Return-Path: <yaronf.ietf@gmail.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 4712212D0B8 for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 09:21:45 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 08I8Ju3looxT for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 09:21:43 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 89CDC12D0F1 for <tls@ietf.org>; Sat, 4 Jun 2016 09:21:42 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id a136so35484870wme.0 for <tls@ietf.org>; Sat, 04 Jun 2016 09:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=wUTi7+bcpSuY6Ozno4QvvRPgrbyCAq0Fya8ODLHtMfQ=; b=XnhdRwwsI/MAa2mKNoLpuCXGyJBJCDV+AZXKR1Uz650M41+/c+6VfhV9OSOYdvsR+9 7syC/OclaDuR9s6rtVYLqAgJZ5ho1y9drMHDe1cj7dvz00txpFyaf0shNAVuhZBCvkOY y2EmuuZTxgC10oCirXUJGy1JXadxwnTcF1wGPnwDcphzzp7oQ0tVwdv6i1eHCiBZaf8M SAV1ZKyfNIkf+Sdy4x4ThMhY7X2p8X5RpEmZWIA7Kz1UQBq2wIwmzYCN5X2dhk+N53Ej fBQtqciwLsvqKfow32kZawiogW4pJgj/825ZcrIKZyYbxSRfYQV3TOHUeLAmWcIEHUxL DDOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wUTi7+bcpSuY6Ozno4QvvRPgrbyCAq0Fya8ODLHtMfQ=; b=cF4/x0uEVg2eUgXArYKSmC7ipL71a5PBs8jc0Ay9n37CPxFWvgG3Wnxp9B90YCq1f6 RapW15eivXs960Xo28kmz32Vj5rGQmQSrKlSLqjMhxxwEwJdIfyloYptPepubw3E+K1e sNlVt2lEftmywBCmw3fWSZFLVoAibA69uyBThwvJ6PI/vd/CPNyuVF6vcL85sAWAzLJQ 6Tiab+FQ51cbYltLVGbrmwFI5L+TiRFTsn9h2Y/0S+Ev+dFKH70MdCK+OWOcI+oemH/w Uu8FHGqGdg+/yjGr7/EY+QwYil6xzBMofXGPLTxffFWo9B9mLEWO1q4GPdNVNRR4pKes QtMQ==
X-Gm-Message-State: ALyK8tK1QiNODqXP7q7G7HGvrcWA46x/I/Y728+vWXIzwmkmPp+iWqU+3SMg0dTbd0SzqA==
X-Received: by 10.194.201.162 with SMTP id kb2mr9146661wjc.55.1465057300992; Sat, 04 Jun 2016 09:21:40 -0700 (PDT)
Received: from [10.0.0.9] (bzq-109-67-2-59.red.bezeqint.net. [109.67.2.59]) by smtp.gmail.com with ESMTPSA id y1sm11295489wjl.31.2016.06.04.09.21.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 09:21:39 -0700 (PDT)
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com>
From: Yaron Sheffer <yaronf.ietf@gmail.com>
Message-ID: <57530011.50905@gmail.com>
Date: Sat, 4 Jun 2016 19:21:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/iAur0xtR1_jC2_jZubOrdQelm3o>
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:21:45 -0000

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.

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? If so, maybe the client should 
indicate how much concurrency it plans to use?

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

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
>