[TLS] PR#875: Additional Derive-Secret Stage

Eric Rescorla <ekr@rtfm.com> Thu, 09 February 2017 21:16 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414341295CD for <tls@ietfa.amsl.com>; Thu, 9 Feb 2017 13:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 MaWk8HWIybtt for <tls@ietfa.amsl.com>; Thu, 9 Feb 2017 13:16:34 -0800 (PST)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 E98D2129484 for <tls@ietf.org>; Thu, 9 Feb 2017 13:16:33 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id l19so10068251ywc.2 for <tls@ietf.org>; Thu, 09 Feb 2017 13:16:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6/yiItTWgg4Mu6W9g3KJtjrl+naH7alhl0ORGuY+qKg=; b=oKFSwb+83GIClwlKDzs2eksMzMCwXnW6AVbfYp10syCg2S1NbpkDoUKZzEiWR5VuKT 9lNWlIQWpnChuF378mlV9ACiwGpYZfZmR2EDlhCv7PP5A9mi2AWbgF9/CcyMefaea8o8 917BBvSX1MURXehbCQtyrD01+pFceDfVMzIETpgEfW/5m4n/Fo43mQDYXkTfZ48+sjtr XborBIII6ANFl7XEOoDwcPkYabvxJVVYiukkAGwvqOJRLb1HcHGbhcjVAaVQfhFScAu/ rr6nO48ei1Q20J3Tj6r86wGJFhe8buoAYaj+7sUbhRpRGR7nIFW93Sww4MonRyjXQaak JjZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6/yiItTWgg4Mu6W9g3KJtjrl+naH7alhl0ORGuY+qKg=; b=jpSavjE0jnQwDmUJRavBe4y13G6ZSECzu8aOQHBUGUqU8D+8s5sVGOSfG6GC8gcO9p u7m0ynGqKcd4pO42Uh36VLoi4uqe4GTUR95Jl13bJ9+y33Lv+RNdzrbtLxXnfcdOryv4 tq617bx0yDWE7WbOh+B7ApCuXTowr6rBlwMWVwVQVxo4rwmQYFc45W1HyYTsu0BQF9+2 1Lvq9j7MaYGQUfyFbDUgnWIBQFj3JJ8bTlVIXK70DHK0HV8O01OtmlK5g+IAKYM4DmuG 6Y7rPpvV6Zcfvt4kS3RLwY16MRScwz/yrdaFOf7An/Os/JIOSRJK/kEo201ykatBRUX0 yNtA==
X-Gm-Message-State: AMke39kBC9DoZ7UxxL/Lu/jro5Bsx+UW/grx4W4NJDO9SsXPTvq7jnbVLHivSXnE3pH2HUE9IcqiKIcSsqepxA==
X-Received: by 10.129.162.130 with SMTP id z124mr4316682ywg.276.1486674992773; Thu, 09 Feb 2017 13:16:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Thu, 9 Feb 2017 13:15:52 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 09 Feb 2017 13:15:52 -0800
Message-ID: <CABcZeBNLWG5ORRJ0cAVpG7H9w6q7kXS_O9PFQSeNOheLG+nyMA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c129292d7856905481f7e04"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cS4vdMvENOGdpall7uos9iwZ5OA>
Subject: [TLS] PR#875: Additional Derive-Secret Stage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 09 Feb 2017 21:16:35 -0000

I've just posted a pull request which slightly adjusts the structure of key
derivation.
PR#875 adds another Derive-Secret stage to the left side of the key ladder
between each pair of HKDF-Extracts. There are two reasons for this:

- Address a potential issue raised by Trevor Perrin where an attacker
  somehow forces the IKM value to match the label value for Derive-Secret,
  in which case the output of HKDF-Extract would match the derived secret.
  This doesn't seem like it should be possible for any of the DH variants
  we are using, and it's not clear that it would lead to any concrete
  attack, but in the interest of cleanliness, it seemed good to address.

- Restore Extract/Expand parity which gives us some flexibility in
  case we want to replace HKDF.

I don't expect this change to be controversial and I'll merge it on Monday
unless I hear objections.

Thanks,
-Ekr