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

Dave Garrett <davemgarrett@gmail.com> Sat, 18 July 2015 04:38 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 91D361A9233 for <tls@ietfa.amsl.com>; Fri, 17 Jul 2015 21:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xdlhAOq20aBr for <tls@ietfa.amsl.com>; Fri, 17 Jul 2015 21:37:59 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 1EE901A9174 for <tls@ietf.org>; Fri, 17 Jul 2015 21:37:59 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so81548058qkd.3 for <tls@ietf.org>; Fri, 17 Jul 2015 21:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=wRvpaHJK4Xyomrqnw4qWXkKOv2ribVSis5/MzDR8xNY=; b=tfFm1k2NonJrdYLd4LzJcSUPjOj6/XzadyYJL7FDp+lOdudRq5zqi4MChes88Hx4Kk mS1n+vO4r8Z19RYcB73SqSqPER0cnkbdntBQiBswG/IDy2MuNy4YAd25OvmuvYpMv4F5 FkL9Dk7oyewvNBwgNF1D0GJSDfzSm8Rd3L6DPUcVSnlLzTYnU+2xVEFkhk+Hg+DfPSfZ yhOI6EFsGA+Vc8Hr3OxRNhBsH1dgLrgSoC2AonIM3YDigvwsEiPemKdRPpfp14Go1bLS 8+mGKcfDuH2JhKa26zh4uv1CjW71SpqTrPj9iueRvHVDFb73YLuEP8TDm/deSD8sZi44 rdbA==
X-Received: by with SMTP id z100mr31460271qkg.7.1437194278347; Fri, 17 Jul 2015 21:37:58 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id s5sm6995808qgs.1.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 Jul 2015 21:37:57 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, Brian Smith <brian@briansmith.org>, Eric Rescorla <ekr@rtfm.com>
Date: Sat, 18 Jul 2015 00:37:55 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201507180037.56413.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/svJCqDgWgUAprzhrNHDkmDJmMBE>
Subject: [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:38:00 -0000

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?

No PR yet. Just a WIP branch to spec out the idea, so far.