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

Eric Rescorla <ekr@rtfm.com> Sun, 19 July 2015 21:11 UTC

Return-Path: <ekr@rtfm.com>
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 E79EE1B2CC9 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 14:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 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] 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 0STtwrrwSdB7 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 14:11:23 -0700 (PDT)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 2F1851B2CC0 for <tls@ietf.org>; Sun, 19 Jul 2015 14:11:23 -0700 (PDT)
Received: by wgkl9 with SMTP id l9so117212303wgk.1 for <tls@ietf.org>; Sun, 19 Jul 2015 14:11:22 -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:from:date :message-id:subject:to:content-type; bh=cnMClM/iQQQYSrmlJr+ZwpJNaU0PtQWv4sOyp2t9s5M=; b=HeGaAKQ3w1Ga1lAkhdo5j172Chyi9a4uWBHoEPh2c9n+J0zm+pVrvxKkbqDq9pTJ5A iSnlZa0nXw73Q2S1ZQ5ZMb4YGRIMTGVhoxhQzV8M4h63PzB2SsTKe5y62IuWSGneBs6b WMrAez13x8fqafUeekd3+vCEpKVPpYFBDm+R84acZkbBRsiKTNt3wUJPigwHStnOz6qw whlPniMxp1ONC4Dl5EnWHjNBBIoVPa/EgW5Ie8cRjNmE4Kd9EJGj+9Z3xQ6Sr6pwTH3I XwhNrYPZkYIVr8FYVdIRxwkS8JaqbgRYDT0NCYd6KTfGj0FUdR9RG4B8mQNFjjICVeqy 4A5Q==
X-Gm-Message-State: ALoCoQmSxFug8Cls3CDNyuxvrzcEiea1VtNypHCDtdy91yeuQCdvRzv+u15eI/X+AmheLn3LgiA8
X-Received: by 10.180.87.168 with SMTP id az8mr15774934wib.53.1437340281925; Sun, 19 Jul 2015 14:11:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 14:10:42 -0700 (PDT)
In-Reply-To: <20150719210356.GQ28047@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> <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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 19 Jul 2015 23:10:42 +0200
Message-ID: <CABcZeBPsvYumumz5F5rc1mo+KJuwGutmuFrUz30STYVt8CtG+Q@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="90e6ba181b82ed0f17051b40dc10"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/X_mWXYCPGyu1oC-e7HumozS6R5g>
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 21:11:26 -0000

On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:
>
> > Here's the part that is not is still not
> > clear to me: Is the SessionTicket extension still to be used or not?
>
> While we now have
>
>    https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4
>
>        In TLS 1.2 and below, this functionality was provided by "session
>        resumption" and "session tickets" [RFC5077].  Both mechanisms are
>        obsoleted in TLS 1.3.
>
> at the same time we also have:
>
>    https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11
>
>        After the server has received the client Finished message, it MAY
>        send a NewSessionTicket message.  This message MUST be sent before
>        the server sends any application data traffic, and is encrypted
> under
>        the application traffic key.  This message creates a pre-shared key
>        (PSK) binding between the resumption master secret and the ticket
>        label.  The client MAY use this PSK for future handshakes by
>        including it in the pre_shared_key extension in its ClientHello
>        (Section 6.3.1.5.4) and supplying a suitable PSK cipher suite.
>
>          struct {
>              uint32 ticket_lifetime_hint;
>              opaque ticket<0..2^16-1>;
>          } NewSessionTicket;
>
>        ticket_lifetime_hint
>           Indicates the lifetime in seconds as a 32-bit unsigned integer in
>           network byte order.  A value of zero is reserved to indicate that
>           the lifetime of the ticket is unspecified.
>
>        ticket
>           The value of the ticket to be used as the PSK identifier.
>
> and
>
>    https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4
>
>        The pre_shared_key extension is used to indicate the identity of the
>        pre-shared key to be used with a given handshake in association with
>        a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).
>
>          opaque psk_identity<0..2^16-1>;
>
>              struct {
>                select (Role) {
>                  case client:
>                    psk_identity identities<0..2^16-1>;
>
>                  case server:
>                    psk_identity identity;
>
>              } PreSharedKeyExtension;
>
>        identifier
>           An opaque label for the pre-shared key.
>
> 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)

-Ekr


>
> > 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.
>
> In the current 1.3 draft, there is indeed no client signal.
>
> > 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.
>
> The client lifetime is not that useful with session tickets anyway,
> whether the client caches at all, could be, but it is not clear
> that the resulting "inefficiency" needs to be fixed.  The fix would
> be for the client to send an empty extension of some sort to signal
> its desire to elicit a session ticket.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>