IETF Logo Mail Archive

Re: [TLS] TLS 1.3 multiple session tickets from the client?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 10 May 2018 13:46 UTC

Return-Path: <ietf-dane@dukhovni.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 37A95124217 for <tls@ietfa.amsl.com>; Thu, 10 May 2018 06:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 4p-n_7lu1ZMP for <tls@ietfa.amsl.com>; Thu, 10 May 2018 06:46:46 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F93C12EAD4 for <tls@ietf.org>; Thu, 10 May 2018 06:46:46 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 586A57A3309 for <tls@ietf.org>; Thu, 10 May 2018 13:46:45 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBPqVTWaZ5pXBf66jt+2m0rXA6LoqaddQB8onvwjE+39QQ@mail.gmail.com>
Date: Thu, 10 May 2018 09:46:44 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <71974FFA-DEA4-4C66-BDAE-FAD7BF46463B@dukhovni.org>
References: <773A6343-2978-4195-BF53-B5253E3B9129@dukhovni.org> <CABkgnnXNnheqdRBO_h6XVK5uvr-qoM9_xSMq4EEH5CgKLWqabw@mail.gmail.com> <CABcZeBPqVTWaZ5pXBf66jt+2m0rXA6LoqaddQB8onvwjE+39QQ@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YYd-a5XxQHV21zDNOMyHQdMSZPQ>
Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 10 May 2018 13:46:49 -0000


> On May 10, 2018, at 7:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> The option for multiple PSKs is something that is used in pure PSK modes,
> but I confess to not fully understanding the reasons you might use multiple
> PSKs.  I suspect that they are most useful during a key rollover.
> 
> Also, resumption of sessions created with PSKs

So I am not hearing any intent to support multiple resumption PSKs
(session tickets) in the same handshake.

How are TLS 1.3 server implementations approaching distinguishing
between external PSK identities and (RFC5077) resumption PSKs, so
that one does not end up looking for RFC5077 key names to decrypt
an external PSK, or pass resumption PSKs to the code that implements
external PSKs?

Do you prepend some new "magic" to the (RFC5077 or similar) session
tickets?  Or just look for a matching STEK key name and let that be
the "magic"?

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email