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

Eric Rescorla <> Sat, 18 July 2015 04:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C6F941AC3FC for <>; Fri, 17 Jul 2015 21:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id htAqb0-x3pYs for <>; Fri, 17 Jul 2015 21:51:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 043301AC3E5 for <>; Fri, 17 Jul 2015 21:51:21 -0700 (PDT)
Received: by wgbcc4 with SMTP id cc4so1767265wgb.3 for <>; Fri, 17 Jul 2015 21:51:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id az8mr1696282wib.53.1437195079795; Fri, 17 Jul 2015 21:51:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Jul 2015 21:50:40 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Fri, 17 Jul 2015 21:50:40 -0700
Message-ID: <>
To: Dave Garrett <>
Content-Type: multipart/alternative; boundary="90e6ba181b823457ce051b1f0e30"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets
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: Sat, 18 Jul 2015 04:51:26 -0000

On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett <>

> 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":
> 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:
> 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
  connection, since compromise of either endpoint probably allows
  attacks going forward.

- Because the resumption master secret is cryptographically independent
  of the master secret that initiated the connection, its existence in the
  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
  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.)