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.
- [TLS] TLS 1.3 - method to request uncached shared… Dave Garrett
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- Re: [TLS] TLS 1.3 - method to request uncached sh… Brian Smith
- Re: [TLS] TLS 1.3 - method to request uncached sh… Dave Garrett
- Re: [TLS] TLS 1.3 - method to request uncached sh… Salz, Rich
- Re: [TLS] TLS 1.3 - method to request uncached sh… Dave Garrett
- Re: [TLS] TLS 1.3 - method to request uncached sh… Ilari Liusvaara
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- Re: [TLS] TLS 1.3 - method to request uncached sh… Viktor Dukhovni
- Re: [TLS] TLS 1.3 - method to request uncached sh… Brian Smith
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- Re: [TLS] TLS 1.3 - method to request uncached sh… Brian Smith
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- Re: [TLS] TLS 1.3 - method to request uncached sh… Dave Garrett
- Re: [TLS] TLS 1.3 - method to request uncached sh… Viktor Dukhovni
- Re: [TLS] TLS 1.3 - method to request uncached sh… Viktor Dukhovni
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- Re: [TLS] TLS 1.3 - method to request uncached sh… Dave Garrett
- Re: [TLS] TLS 1.3 - method to request uncached sh… Brian Smith
- Re: [TLS] TLS 1.3 - method to request uncached sh… Viktor Dukhovni
- Re: [TLS] TLS 1.3 - method to request uncached sh… Viktor Dukhovni
- Re: [TLS] TLS 1.3 - method to request uncached sh… Dave Garrett
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- Re: [TLS] TLS 1.3 - method to request uncached sh… Eric Rescorla
- [TLS] crypto computations & lifetimes clarificati… Dave Garrett
- Re: [TLS] crypto computations & lifetimes clarifi… Eric Rescorla
- Re: [TLS] crypto computations & lifetimes clarifi… Hugo Krawczyk
- Re: [TLS] crypto computations & lifetimes clarifi… Dave Garrett