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

Brian Smith <brian@briansmith.org> Sun, 19 July 2015 20:40 UTC

Return-Path: <brian@briansmith.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 C609F1B2C1E for <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Sun, 19 Jul 2015 13:40:16 -0700 (PDT)
Received: by oihq81 with SMTP id q81so98354849oih.2 for <tls@ietf.org>; 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: <CABcZeBPT2RZe1nR5hZCxSgO+GoHoYAPpmuV7FucZrX6TyRB-qQ@mail.gmail.com>
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> <20150719171657.GL28047@mournblade.imrryr.org> <CAFewVt7qc6pE_NNdO16FOAhohD=YCmiX1VmSYgpHzbjqtxJevw@mail.gmail.com> <CABcZeBPT2RZe1nR5hZCxSgO+GoHoYAPpmuV7FucZrX6TyRB-qQ@mail.gmail.com>
Date: Sun, 19 Jul 2015 16:40:15 -0400
Message-ID: <CAFewVt7tuJBpKggc2MND4m_LxLHb+iGupOAVAKRJBRPZMDVo3g@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=089e0149d1b2b07972051b406d1f
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HlTEDITdhrc72n9K4kQxHly5WAs>
Cc: "<tls@ietf.org>" <tls@ietf.org>
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." <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 20:40:21 -0000

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 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/