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

"Jim Schaad" <ietf@augustcellars.com> Sat, 04 June 2016 17:23 UTC

Return-Path: <ietf@augustcellars.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 2B08E12D52E for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 10:23:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 YOcwsxIxag_5 for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 10:23:16 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F013912D0BB for <tls@ietf.org>; Sat, 4 Jun 2016 10:23:15 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 4DC5B2CA42; Sat, 4 Jun 2016 10:23:15 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Eric Rescorla'" <ekr@rtfm.com>, <tls@ietf.org>
References: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com>
In-Reply-To: <CABcZeBMo9U7_wZeXpEosPFa4KiC4eq3LGOvDtSAy5NNz7jc0dQ@mail.gmail.com>
Date: Sat, 4 Jun 2016 10:23:14 -0700
Message-ID: <001e01d1be85$c72a21d0$557e6570$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01D1BE4B.1ACCA960"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKepLaZ/vuU61WRgcf4yhfWJQHKR54/wYyA
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JxpEr0eR-OtoBLxjM1bju85H3Xg>
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:23:18 -0000

What about the choice of, randomly use any of the tickets but don’t re-use a ticket?  I am not sure why using them in a specific order is better or worse.  Even if you assign a specific ticket to a reconnect, I would expect that timing of issues might make the server see the tickets out of order so that it needs to deal with the fact that they come in randomly. 

 

Jim

 

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Saturday, June 04, 2016 8:51 AM
To: tls@ietf.org
Subject: [TLS] PR #493: Multiple concurrent tickets

 

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