Re: [TLS] TLS 1.3 - method to request uncached shared secrets
Eric Rescorla <ekr@rtfm.com> Sat, 18 July 2015 04:51 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 C6F941AC3FC for <tls@ietfa.amsl.com>; Fri, 17 Jul 2015 21:51: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 htAqb0-x3pYs for <tls@ietfa.amsl.com>; Fri, 17 Jul 2015 21:51:24 -0700 (PDT)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 043301AC3E5 for <tls@ietf.org>; Fri, 17 Jul 2015 21:51:21 -0700 (PDT)
Received: by wgbcc4 with SMTP id cc4so1767265wgb.3 for <tls@ietf.org>; Fri, 17 Jul 2015 21:51:19 -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=ywhVbPjs7Ji6zvUteDJg3Mw+aRo1u3rzgnnsLDwuXNo=; b=UdUPDkjgUrtmTxpxPGKwfsrypeTr2JoHcOKZXV76zUjOepUOtyp8viYwPA/BwDZMPv kAXO6yvTGW4JTjlsiin7EzZRdNBgEBZkX/ccQWjY7I4Fm9aKl+LN+hN6JSZ+LN9dsUXt 53+VB8yKKsgh+Scx0nm5+8DQvrKlq6T3GeXRdp1L680hsrri7umAeu+IqR4mUGmMJBtv zOVOBoKZKFedMu9C8PFgOXWa0LwiFZR1mJlLks+xEZQMzeCEqqYfWoedJV3ZLv1POdN4 RGHhZLYXwibDZBEZ/ElXgGzSx1YpiZOrBmW3kwZ6e4T+FPtOE+Enrslk7N/u+8ICRocW Re2g==
X-Gm-Message-State: ALoCoQnLumEVeUJppHgeCEUDM7dYsFpsDA+3BGf9R/pypmgbOfu8ih1w8dO7Iq2bDzPFOfGET3af
X-Received: by 10.180.87.168 with SMTP id az8mr1696282wib.53.1437195079795; Fri, 17 Jul 2015 21:51:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Fri, 17 Jul 2015 21:50:40 -0700 (PDT)
In-Reply-To: <201507180037.56413.davemgarrett@gmail.com>
References: <201507180037.56413.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 17 Jul 2015 21:50:40 -0700
Message-ID: <CABcZeBMv693fqYenRH9ix6zXpxFUtwPEq+wxCc3gKpDUxY97eQ@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="90e6ba181b823457ce051b1f0e30"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/VwibeYxcha3Gx6pfM6xShmBAmmY>
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: Sat, 18 Jul 2015 04:51:26 -0000
On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett <davemgarrett@gmail.com> wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 > > The goal is to provide a simple way for either endpoint to request that > the master secret be forgotten ASAP to provide a greater assurance of > confidentiality. > > I've written up a short proposal with idea about how I'd suggest going > about this: > > https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify > > The idea is to simply add a new "reset_notify" alert (generally a warning) > which may be sent by either endpoint as soon as record protection is > available, after which both endpoints would stop caching shared secrets > after completion of traffic key completion. This could be sent right from > the start, at the end of a connection just prior to a standard > "close_notify", or at any point in between. > > This seems like a simple route that does what is specified in issue #137 > without the creation of any new extensions or messages; just one new alert > value. > > Comments? Suggestions? Any reason this would break everything? > I don't think this is that useful or practical with the current structure of TLS 1.3. - Unless I've missed something, this is primarily an issue of PFS for the original connection, since compromise of either endpoint probably allows impersonation attacks going forward. - Because the resumption master secret is cryptographically independent of the master secret that initiated the connection, its existence in the server's database or in a ticket isn't a threat to the originating connection. - The server can opt not to allow resumption by declining to provide a NewSessionTicket message. - The client has the option of never initiating a new connection with the provided ticket (assuming that the server opts to supply one). Note also that because the ticket is encrypted with the original traffic keys, if the client never tries to resume the connection, the ticket never appears on the wire (which is relevant for self-encrypted tickets, but not so much for tickets which are database lookup keys). - Because many implementations use self-encrypted tickets, it's not practical to require them to delete keying material once it's been established. Once such a ticket has been transmitted on the wire, the server can't really forget it without deleting the ticket encryption key (it can of course mark the ticket invalid in some local database, but that doesn't reduce the risk from compromise of the ticket encryption key.) -Ekr
- [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