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

Dave Garrett <davemgarrett@gmail.com> Mon, 20 July 2015 18:19 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 7D5D11B2A80 for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 11:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
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 eOghKJTQhHkF for <tls@ietfa.amsl.com>; Mon, 20 Jul 2015 11:19:40 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 796FE1B2A8E for <tls@ietf.org>; Mon, 20 Jul 2015 11:19:40 -0700 (PDT)
Received: by qgy5 with SMTP id 5so76572979qgy.3 for <tls@ietf.org>; Mon, 20 Jul 2015 11:19:39 -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=2z2VwNnBHSPuGxF7J4CCJXQoM+ITeK/X0yQ+kFO7q88=; b=Oo2BdA3eVc/kRHdUpsoHGxdvE/cxBVEJJAI/mBHk8Rz2O6gBGp/MH2YI9owF3E3Fz8 kGlhvRNmS5ixjpWtm15xXq9ErhXwxhzLRfsS2dsyC6gHVJkxaWuVoYjAPOyAxoY5fAY8 XxI7lWI60ABGHgurioGJNtRJX9ZdNGhnOtQmWKdN7l/zxoz+vjdjMXH7Zjk6aeCqsfdU UGjW/c63OKwiN/m2e8YC9GjNe2upPxZ9RG8MhPfeTSVeiQPteTXk3ByRiIwFLyLNDNKa +uv0m9egbDiiPkQ3ENiAkQwBLPtWUVYWXlN2F5N8QPMxdyUeW9f0C8JzH100HirYMCdp ptUg==
X-Received: by 10.140.150.198 with SMTP id 189mr43748113qhw.88.1437416379741; Mon, 20 Jul 2015 11:19:39 -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 k16sm11348182qgd.23.2015.07.20.11.19.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jul 2015 11:19:39 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Mon, 20 Jul 2015 14:19:37 -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> <CABcZeBM9c+jBTRfOhJUJDbC3jJ9Uu8Uod3LK4D-RhA9S=51Q_A@mail.gmail.com> <CADi0yUMODP-zfmmkRDvKx_-DTVNVMONSa92Bw1kW1+-hgRn27Q@mail.gmail.com>
In-Reply-To: <CADi0yUMODP-zfmmkRDvKx_-DTVNVMONSa92Bw1kW1+-hgRn27Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201507201419.37691.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_G-yKqSYLrFnQQR5qpAMKGD2UWg>
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 18:19:41 -0000

On Monday, July 20, 2015 01:31:15 pm Hugo Krawczyk wrote:
> Your question boils down to: Why is finished_secret derived from SS only
> and not from ES?
> 
> First note that the issue only arises in the known_configuration case since
> in other cases ES and SS are the same.
> For the known_configuration case there are two important reasons
> ​to build on SS and not on ES:
> ​
> 1. Only SS can authenticate the handshake as it is the only element to
> involve the server's (semi) static private key.
> 2. One of the main elements to be authenticated by the server (via the
> Finished message) is the ServerKeyShare, thus deriving the key for the
> Finished message (i.e. finished_secret) from ES (calculated using
> ServerKeyShare) would create a circularity issue in the logic of the
> derivation.
> 
> Note that the derivation of application keys (and other key material
> remaining after the end of the handshake) do involve both SS and ES, but in
> that case involving ES is crucial to achieve forward secrecy.

Thanks for the explanation.

Using the master secret could work, but adding the ES isn't productive so using the SS directly makes more sense than mixing SS+ES first.


Dave