Return-Path: 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 C609F1B2C1E for ; Sun, 19 Jul 2015 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 D6tQD8qPbl4f for ; Sun, 19 Jul 2015 13:40:16 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E851B2C0F for ; Sun, 19 Jul 2015 13:40:16 -0700 (PDT) Received: by oihq81 with SMTP id q81so98354849oih.2 for ; Sun, 19 Jul 2015 13:40:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OnFbENUDu7H52YVU+MK3dL9jSLf6NzOmTD83zLQTr00=; b=IOpiLO7C+ANtccp/r3hCpfOzC1sqDXPmTDmVwI60ywn58y+15deRBCCNizrfFDv1K7 MGAR0eIJ1V3PYAGicy/2V1INckjjvg2/DXWwpFRa6/2Cf9r0EiaxEFeuxVFIs2pFeXtD JvHaPC1u2dvGm3/M9TKQtv4e/bkanzcuQ3+xXlUJ3Cm3rcZ+mm4X6ixeLDctdcrLrT/K DFJUZrV99PbQ281CtzRtDJ5gnuUiO6+OlYj9Y62TSkNRycVnJKfp16uRxuAsptYoltiE ZA6MnT0LOf969QNr32PQqwPb1g7igB2mLGIZ1q74wiioL/9vIFJ00PusUAlTOw95ueiB r2wg== X-Gm-Message-State: ALoCoQl+jdw3aDRBcmJifwa1r/08y/xyvgdj783xkdTfZxLtS9k9HSwHLCZpr1SCgGxPt5avS88I MIME-Version: 1.0 X-Received: by 10.60.59.102 with SMTP id y6mr23537186oeq.53.1437338415685; Sun, 19 Jul 2015 13:40:15 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Sun, 19 Jul 2015 13:40:15 -0700 (PDT) In-Reply-To: References: <201507180037.56413.davemgarrett@gmail.com> <201507181428.40766.davemgarrett@gmail.com> <20150719125016.GA17542@LK-Perkele-VII> <20150719171657.GL28047@mournblade.imrryr.org> Date: Sun, 19 Jul 2015 16:40:15 -0400 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0149d1b2b07972051b406d1f Archived-At: Cc: "" 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 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 20:40:21 -0000 --089e0149d1b2b07972051b406d1f Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith > wrote: > >> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft >> actually contains a regression here. It seems like it is no longer possible >> for the server to indicate how long a PSK should be held by the client to >> resume a session, >> > > Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint > value. > > http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 > > and it seems like it is no longer possible for the server to indicate that >> it doesn't support resumption. >> > > Well, it can't indicate it, but if it doesn't supply a session ticket, > there's no way for > the client to do it. > Great. I was misunderstanding. Here's the part that is not is still not clear to me: Is the SessionTicket extension still to be used or not? It seems not, AFAICT. If the SessionTicket extension were to be used, then everything would work perfectly as Viktor suggested in his message: the absense of the SessionTicket extension in the ClientHello would be the way that a client can indicate that it doesn't want the session to be cached. It seems weird that the server can supply a lifetime hint but the client can't, especially in cases like WebRTC where there is no functional difference between the two. But, that's a smaller issue than the lack of an indication that resumption machinery isn't wanted at all. Cheers, Brian -- https://briansmith.org/ --089e0149d1b2b07972051b406d1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
= On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <brian@briansmith.org= > wrote:
Maybe I'm misunderstanding, but= it looks like the current TLS 1.3 draft actually contains a regression her= e. It seems like it is no longer possible for the server to indicate how lo= ng a PSK should be held by the client to resume a session,

Not unless I've made a m= istake. NewSessionTicket contains a lifetime_hint value.


<= div class=3D"gmail_extra">
and it seems lik= e it is no longer possible for the server to indicate that it doesn't s= upport resumption.

Well, it can't indicate it, but if it doesn't supply a sessi= on ticket, there's no way for
the client to do it.

Great. I was misunderstanding= . Here's the part that is not is still not clear to me: Is the SessionT= icket extension still to be used or not? It seems not, AFAICT. If the Sessi= onTicket extension were to be used, then everything would work perfectly as= =C2=A0Viktor suggested in his message: the absense of the SessionTicket ext= ension in the ClientHello would be the way that a client can indicate that = it doesn't want the session to be cached.

It s= eems weird that the server can supply a lifetime hint but the client can= 9;t, especially in cases like WebRTC where there is no functional differenc= e between the two. But, that's a smaller issue than the lack of an indi= cation that resumption machinery isn't wanted at all.

Cheers,
Brian
--
--089e0149d1b2b07972051b406d1f--