Re: [TLS] Resumption ticket/PSK

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 19 May 2016 20:50 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 20A1E12D688 for <tls@ietfa.amsl.com>; Thu, 19 May 2016 13:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 j_xp86mXiw-i for <tls@ietfa.amsl.com>; Thu, 19 May 2016 13:50:23 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4E912D67C for <tls@ietf.org>; Thu, 19 May 2016 13:50:23 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8C6A5284F26; Thu, 19 May 2016 20:50:22 +0000 (UTC)
Date: Thu, 19 May 2016 20:50:22 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20160519205022.GI3300@mournblade.imrryr.org>
References: <CAJU8_nVhM+xOnt8D8UJ8qvWUFts3s5n3gOQvJZYs=XWymfVOVQ@mail.gmail.com> <CABcZeBM8R8LC0wQfxp63BzfjRvLh4sYh4HdT5KZ8LXe2uE3GgQ@mail.gmail.com> <20160519190508.GE3300@mournblade.imrryr.org> <CAJU8_nW5jqO3DSvZZNpNQThnCb3P4bCBjE47uhjPRPB1ix6_mg@mail.gmail.com> <20160519191930.GF3300@mournblade.imrryr.org> <CAJU8_nXkSLxWJ3NdoXrqAgg3vD_mxRmGET82Di==wy9tSAewbA@mail.gmail.com> <20160519200124.GG3300@mournblade.imrryr.org> <CABkgnnWpNHxchq8GOCObL9iqicmmTw4R7gPgRA4m1sh-W43vkA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABkgnnWpNHxchq8GOCObL9iqicmmTw4R7gPgRA4m1sh-W43vkA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wR8y2oHuodB5bwbBG8ZQSMu51p8>
Subject: Re: [TLS] Resumption ticket/PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tls@ietf.org
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, 19 May 2016 20:50:25 -0000

On Thu, May 19, 2016 at 04:37:30PM -0400, Martin Thomson wrote:

> On 19 May 2016 at 16:01, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> > Nevertheless, some clients may want to attempt to gain fine-grained
> > protection against correlating back to back or parallel resumption
> > requests.  For this they'd have to ensure that all session tickets
> > are single use, and either perform new handshakes when increasing
> > the number of parallel connections to the server, or somehow obtain
> > more than one ticket within a single session.
> 
> I believe that this is the intent of the PR.  I've suggested an
> alternative wording that cleaves closer to your text above.

I'm suggesting that instead of servers guessing that clients want
this, it might make more sense to employ an extension to request
single-use tickets.  Session tickets will often encapsulate the
client certificate, and issuing them on every resumption can
considerably increase the size of the server response.  Many clients
will not benefit, so I'm suggesting that this should be optional.

I've not heard many others chime-in yet, so it is not yet clear
where WG consensus may lie on this question.

-- 
	Viktor.