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

Brian Smith <> Sat, 18 July 2015 05:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1BE931AC405 for <>; Fri, 17 Jul 2015 22:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5cVn9LqE9M8w for <>; Fri, 17 Jul 2015 22:06:34 -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 556011AC402 for <>; Fri, 17 Jul 2015 22:06:34 -0700 (PDT)
Received: by oigd21 with SMTP id d21so39756800oig.1 for <>; Fri, 17 Jul 2015 22:06:33 -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:date :message-id:subject:from:to:cc:content-type; bh=bpC6jvzKh+OQLKiyoPfo9o/b+fhOCMKWc+gWEBY1wz4=; b=NisoWN9ohU5YQHHbNcY7LZnCk2oKbk8GfE8c+t7yUSCzgpsIuLn3QTuif6SaI1dmzo L8UzB82VQb9i5uDk1H1BS80XMj6BiRcSThqi7Fpb1acEYTvGgqjFJwcsBdakoapdSkS0 QeZppTHsYlvNeUoSRNpQO/bwU4LZB2G/srf+ZXO7eztbl1gGuRvZ0rqDpb6UHgFw3LDp w0JpPKato0ZfWJko1g24H7ZC3VWqaQ1CWoSksXxLWz7Gfl1nDRv/aj3I83A7qz9eChFT 1ExfCFJuI+nXqrOEsIP00iShH3HOf337B/hwPdYdtruKKX4/ajMe7IhlWu0K5iq9AW0p 66QQ==
X-Gm-Message-State: ALoCoQlQBUsKzMoeKgvWbi3kjvyU0bR75g2SFos11udGjSg3iI3ecf3Y4wtAXuhMwqALYoJhcIU6
MIME-Version: 1.0
X-Received: by with SMTP id j65mr15783944oig.68.1437195993760; Fri, 17 Jul 2015 22:06:33 -0700 (PDT)
Received: by with HTTP; Fri, 17 Jul 2015 22:06:33 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sat, 18 Jul 2015 01:06:33 -0400
Message-ID: <>
From: Brian Smith <>
To: Dave Garrett <>
Content-Type: multipart/alternative; boundary="001a113d2b38ae5f69051b1f44e9"
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 05:06:36 -0000

Dave Garrett <> 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":
> 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 is not really what I was intending when I suggested the feature. I was
intending for their to be an indication, in the ClientHello, that the
server should not do any of the work that it would normally do to make the
session resumable. That is, the server MUST NOT create a session ticket,
and the server MUST NOT add the connection to any session cache, the server
SHOULD forget the epheneral (EC)DHE key and master secret ASAP during
handshaking. (And, so should the client.)

An alert like you suggest may be useful for some cases, but it wouldn't be
useful for what I was suggesting because it would occur after the server
has already done all the things to cache a session that add needless risk
and waste resources when the client has no intention of resuming the

In the context of web browsers, I believe that the Tor Browser would prefer
to have this, since it disables session resumption to prevent the leaking
of the tracking identifier inherent in it. It would also be useful for any
(non-browser) application for which a 1-RTT handshake per connection is
good enough, which is probably most applications, especially many
server-to-server applications.