[TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)

Dave Garrett <davemgarrett@gmail.com> Mon, 20 July 2015 07:04 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7987C1A00B9 for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 00:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WIYhZDuKWXy for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 00:04:27 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 5D09F1A00B0 for <tls@ietf.org>; Mon, 20 Jul 2015 00:04:27 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so107069178qkd.3 for <tls@ietf.org>; Mon, 20 Jul 2015 00:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=4ZAShMftt9kviGyKeWDCIOz4ytrPXTGBEgPJARZJAok=; b=Pz1Rirrvbzji1wrxS0OMfNno2CRMoIT7w0oYFAepr446FpFdu6lIMPh7juTJ0lwre6 a2JQnVSWnDxQS+Mps0ZrClICpI1lZQk3TbUgCJhlzT0kfG/zgG0oHZt4289d3dQgRin5 +xinghfbYpjBAradV+ymMmi8dSkkG7McNLrynKyG7J4yUet9/CS9ZsxtWrszg4nP8eJ3 YQqSqMeE7kdZORP60KNOgue7K9+cix+vY+6V/+vHq0y+sQ/DjfS/fy3yDoanUWYkxIJb JpU8Hhg/7XR5urjChvLbweHTY8Y3QrVKxMCWX18opLH+l08yZn6n4EDXYV4jjn/Ike9h U90A==
X-Received: by 10.140.239.9 with SMTP id k9mr39154672qhc.38.1437375866596; Mon, 20 Jul 2015 00:04:26 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id s91sm10482003qge.44.2015.07.20.00.04.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 00:04:26 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Jul 2015 03:04:24 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201507180037.56413.davemgarrett@gmail.com> <CAFewVt7cyF=7yXqYKHE=RK6x3_n8dgV_6fe2LD9-g-WU-z8BeA@mail.gmail.com> <CABcZeBNArRwpPp9Q5Wjupnhqnw5OssSsmzvpsXNAYJ_Bjfef=A@mail.gmail.com>
In-Reply-To: <CABcZeBNArRwpPp9Q5Wjupnhqnw5OssSsmzvpsXNAYJ_Bjfef=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201507200304.24847.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/W31BEtO5yENJF2ReKTiUPElNpm0>
Cc: tls@ietf.org
Subject: [TLS] crypto computations & lifetimes clarifications (was: 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 07:04:29 -0000

On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> I think perhaps you have misunderstood the forward secrecy properties of the
> current draft. Unlike TLS 1.2 and previous, the current draft has a separate
> resumption master secret which is independently derived from the master
> secret used for the connection keys in the original connection. This means
> that if you don't resume the connection, you have forward secrecy for the
> original connection regardless of whether the server stores the session in
> the session cache or sends the client a ticket.

We've got lots of keys and secrets now. Could you please clarify the exact points where these are each to be discarded? If I am understanding it correctly, the master_secret, prior intermediate secrets, and finished_secret are to be discarded as soon as the keys, resumption_secret, and possibly exporter_secret (which currently has no explanation in the doc) are derived, the handshake is finished, and we're ready for application traffic? It would help if you provided a table/chart laying out the timeline of secret & key lifetimes, from derivation to discard. It should state in the spec explicitly what needs to be kept around for how long and require things be discarded as soon as viable.

I think these various values need to be named more consistently in the doc to make searching for them easier. For example, "resumption_secret" is used in the computation part but the words "resumption master secret" are used when actually using this value. (also noted in issue #191 by Martin Thomson) I've pushed a small PR to correct this case along with a few tweaks that I think makes it a bit clearer.
https://github.com/tlswg/tls13-spec/pull/205

Also, some other questions about various computations:

https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1
https://tlswg.github.io/tls13-spec/#key-schedule

HKDF(,,,) doesn't seem to be fully defined here, just HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. Could you please clarify this?

Why is finished_secret derived from extracted static secret instead of master_secret? There's a TODO about changes to use of the master_secret here; could you explain this bit please? (I assume this is a work in progress)

Are there two finished_secret in the event that the client sends a certificate?

The computation of verify_data could probably be moved up to the same section so this is all in the same place. Am I correct in reading that it could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, finished_label, handshake_hash, L) without the extra HMAC currently defined for verify_data)


Thanks,
Dave