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

Eric Rescorla <ekr@rtfm.com> Mon, 20 July 2015 07:11 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 D69161A00DD for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 00:11: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 N1W_1qGtSsFI for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 00:11:23 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 5AB491A00BB for <tls@ietf.org>; Mon, 20 Jul 2015 00:11:23 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so7502077wic.0 for <tls@ietf.org>; Mon, 20 Jul 2015 00:11:22 -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=DHVbOdgoe/dbtM2WhliMgyaIKLsB9ww9B/tlDvfBst4=; b=fupneafuNPVvvUEr9zr8HDhTc0cDH+Bri7dTkb4DwClBDD6CZOKsbzJZdlzosuEWZ+ 2P/ZWF53K8hhQ4P84ZYDxImBR0EgRHxfLUmoQsO/Y7JbAVkrgEXE7rLHmrhr1NpLF232 em/O7j/TXKen4eQ2cOo/RZcEjTrdJ684v0VZyLa/0j6xG/LLZEmtx/D3sJhvx7aoXOS/ LGqtUjPf4fX1NvMMY6n0vkJspSrjHQNMRAxfxPzxbU4bjUGX8k1gROH1JH5pT9yyjzAJ C2+0MBPXVQyAbRyfHLw5F6/+EaZlJ98WF4d+DV9Xe/AvpywBcH4q3dw+HA6imZ/Idi1p I/7w==
X-Gm-Message-State: ALoCoQliaFsXT+eW37AEoN8cczz42+3rk7kkaq+444pT6rTC4PFDV8J6AMd/mraC0OgxlmjxhGAn
X-Received: by 10.194.79.225 with SMTP id m1mr54454476wjx.8.1437376282019; Mon, 20 Jul 2015 00:11:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Mon, 20 Jul 2015 00:10:42 -0700 (PDT)
In-Reply-To: <201507200304.24847.davemgarrett@gmail.com>
References: <201507180037.56413.davemgarrett@gmail.com> <CAFewVt7cyF=7yXqYKHE=RK6x3_n8dgV_6fe2LD9-g-WU-z8BeA@mail.gmail.com> <CABcZeBNArRwpPp9Q5Wjupnhqnw5OssSsmzvpsXNAYJ_Bjfef=A@mail.gmail.com> <201507200304.24847.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Jul 2015 09:10:42 +0200
Message-ID: <CABcZeBM9c+jBTRfOhJUJDbC3jJ9Uu8Uod3LK4D-RhA9S=51Q_A@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b10c903b36745051b493e5c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/elJkrBGn2tsXuFoNNUS4COhzfdw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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:11:26 -0000

On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> 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.
>

Yes, I can do something along these lines.



> 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?
>

Yes.



> Why is finished_secret derived from extracted static secret instead of
> master_secret?


The rationale here is that the Finished message also serves to authenticate
the server's ephemeral DH share (when in known_configuration mode) and
because the master secret depends on the ephemeral DH keys, this creates
an odd authentication logic. Hugo can expand on this some more, perhaps.



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

No, this shouldn't be necessarily. You just use the first one. I'll try to
clarify.



> 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)


See above.

-ekr