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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 19 July 2015 21:35 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 31A361B2D8A for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 14:35:23 -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 i5wCkp-rdyGJ for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 14:35:21 -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 9F1431B2D8B for <tls@ietf.org>; Sun, 19 Jul 2015 14:35:21 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D8799284B6C; Sun, 19 Jul 2015 21:35:20 +0000 (UTC)
Date: Sun, 19 Jul 2015 21:35:20 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150719213520.GT28047@mournblade.imrryr.org>
References: <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> <20150719171657.GL28047@mournblade.imrryr.org> <CAFewVt7qc6pE_NNdO16FOAhohD=YCmiX1VmSYgpHzbjqtxJevw@mail.gmail.com> <CABcZeBPT2RZe1nR5hZCxSgO+GoHoYAPpmuV7FucZrX6TyRB-qQ@mail.gmail.com> <CAFewVt7tuJBpKggc2MND4m_LxLHb+iGupOAVAKRJBRPZMDVo3g@mail.gmail.com> <20150719210356.GQ28047@mournblade.imrryr.org> <CABcZeBPsvYumumz5F5rc1mo+KJuwGutmuFrUz30STYVt8CtG+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBPsvYumumz5F5rc1mo+KJuwGutmuFrUz30STYVt8CtG+Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pOdNwk6-H1lnTK7m1eW6MsO6gSo>
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 21:35:23 -0000

On Sun, Jul 19, 2015 at 11:10:42PM +0200, Eric Rescorla wrote:

> > So indeed it is no longer possible for the client to signal the
> > ability/desire to resume sessions, and servers will generate session
> > tickets absent any indication that the client intends to use them.
> >
> > This does not impose a space penalty on the server, but some CPU
> > and bandwidth may be wasted on clients that don't or can't resume.
> 
> Yes.
> 
> So my question is whether there are an appreciably large number of servers
> each of which have an appreciably large fraction of *both* caching and
> non-caching clients to make an optimization like this worthwhile (servers
> which only have non-caching or only caching clients can just send
> or not send a ticket as appropriate)

Such a mixture of clients is not at all uncommon with SMTP.  Not
all MTAs implement client-side TLS session caches (no such cache
in Exim or Sendmail).  However, sending a session ticket either
way is not a major burden for SMTP servers.  It would however be
nice to not waste resources doing so, if an appropriate extension
(say the existing one) were used to signal client support.

This is not an absolutely compelling argument in favour of client
signalling, more of an observation that it could be useful.

-- 
	Viktor.