Re: [TLS] TLS 1.3 - method to request uncached shared secrets

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 19 July 2015 17:17 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397BE1A0381 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 10:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 bRlQBA6y9LcR for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 10:16:58 -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 D39901A047A for <tls@ietf.org>; Sun, 19 Jul 2015 10:16:58 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7C930284B6C; Sun, 19 Jul 2015 17:16:57 +0000 (UTC)
Date: Sun, 19 Jul 2015 17:16:57 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150719171657.GL28047@mournblade.imrryr.org>
References: <201507180037.56413.davemgarrett@gmail.com> <CAFewVt72efH+9qYzCSBh1heM7N9Ki-6VrVxbAc0=4UcSf5XbVg@mail.gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <CABcZeBMDujpLqQBtsWG+vutVM8V3g69Ys0_teZ4or=dU-uRwNQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBMDujpLqQBtsWG+vutVM8V3g69Ys0_teZ4or=dU-uRwNQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/apZKFMF1ge0-dE4MBehnllFy8mk>
Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 19 Jul 2015 17:17:00 -0000

On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:

> I'm not seeing a lot of value here. Remember that servers are not
> required (and have never been required) to do session resumption, but
> much of the overhead of doing it (having to have a database, session
> ticket machinery) is associated with being willing to do session
> resumption at all, so if a small fraction of clients would tell
> you that they're not interested in resumption, it's not clear that
> buys you much.
> 
> Are there any server operators who think this is a useful feature
> and can explain why?

These days, I'm operating servers that only support session tickets
(no server-side cache).  If the client does not send the session
ticket extension, no session is cached.

So for servers that elect the same strategy, there's no need for
a separate means to signal the client's intentions.

-- 
	Viktor.