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

Eric Rescorla <ekr@rtfm.com> Mon, 20 July 2015 04:28 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 E79EF1B2F80 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 21:28:40 -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 umV-LWW2PZq4 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 21:28:31 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 826A11B2F83 for <tls@ietf.org>; Sun, 19 Jul 2015 21:28:27 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so85869730wib.0 for <tls@ietf.org>; Sun, 19 Jul 2015 21:28:26 -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:cc:content-type; bh=No0lepCbA2Evr3ca9bBy8JpeZmnWPiXgoTNBuPcVZMY=; b=RiKlyOIPMvUAyHH+uPFwZSnwr639G7mNu4S0932vtMUzfnOzHyydOli4SRq+128kcO 1roLAeXEmYKvEtw1mquPTmfExCQ6cB17IpQc7D5UuFgmaX6zZCfazD2QNM7EVjbeXCm7 gP+7ajAjJ55xLQqzxCQHuS3UP21zbbby1kQgiIFh+vrOq55f9ScXZ/zux7V6teW6YtbB Y/0FSbEs8LzFq2VurQFBE2d/9xfTS8EgbTsUaM3H9c6pbHGeogLOjVB4aKQVBb1E1J/j lPIZHBBeJr1BiGcj3T/0x01I1XV9rS50pmzCES0/AackUF8jtWF/rghuwhadogJr7Bvd f6Ug==
X-Gm-Message-State: ALoCoQmwclBjLmu8oNDtyWBQy5rmZN9fQ/5JqBvQIXaRf/c1eiK+Db276EmFyNeipvcEcVu4+6bU
X-Received: by 10.194.79.225 with SMTP id m1mr53301656wjx.8.1437366506254; Sun, 19 Jul 2015 21:28:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 21:27:46 -0700 (PDT)
In-Reply-To: <201507191812.55108.davemgarrett@gmail.com>
References: <201507180037.56413.davemgarrett@gmail.com> <CABcZeBNpvf-rqYeevWxErhe3Queq76+jmvXZFssoDu7quNah_Q@mail.gmail.com> <CAFewVt7cyF=7yXqYKHE=RK6x3_n8dgV_6fe2LD9-g-WU-z8BeA@mail.gmail.com> <201507191812.55108.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Jul 2015 06:27:46 +0200
Message-ID: <CABcZeBN63_DknAPnbrD0RH3xor0RarKbrNqu31SrOQ5d84fHmA@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b10c9030488ab051b46f86c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/RqUYv5p0MUI4XUUr1E-SzucTtq0>
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: Mon, 20 Jul 2015 04:28:41 -0000

On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> > It depends on how the server implements tickets. The server could
> implement
> > tickets the same way that it implements session ID-based resumption.
> That's
> > not a good idea, but I don't think the spec should prohibit that type of
> > implementation either since it unenforceable. Thus, because of that
> > possibility, it is valuable to have the client be able to say "don't
> cache
> > the session" and/or limit the session's lifetime, so the client can help
> > direct the level of forward secrecy for the session. Right now, only the
> > server has a say in how long a session will be forward-secret.
> >
> > Note also that the NewSessionTicket extension precedes any application
> > data, so without a way to prevent an unwanted NewSessionTicket message
> from
> > being sent, the client has to waste effort and time to consume the
> > NewSessionTicket before it can do anything useful.
>
> If the general ticket lifetime request route is not needed, here's the
> simplest route: just don't drop the Session Ticket extension.
>
>
> https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension
>
> This keeps it with the same semantics for requesting a ticket, thus
> allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2
> servers with no additional effort. TLS 1.3 sessions would be resumed using
> the new PSK-based method and TLS 1.2 sessions would be resumed using the
> old session ticket extension.
>
> Should I submit this as a PR? It seems like the obvious route if all we
> want is to just keep the ability for a client to not request a ticket. No
> need to write a new extension at all.


As I said initially, I'm having trouble seeing why this is particularly
useful.

-Ekr