Re: [TLS] HSM-friendly Key Computation

"StJohns, Michael" <msj@nthpermutation.com> Mon, 20 April 2015 16:09 UTC

Return-Path: <msj@nthpermutation.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 D20841B2F47 for <tls@ietfa.amsl.com>; Mon, 20 Apr 2015 09:09:58 -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 FJOhCeqrOUem for <tls@ietfa.amsl.com>; Mon, 20 Apr 2015 09:09:57 -0700 (PDT)
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (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 51A5D1B2F45 for <tls@ietf.org>; Mon, 20 Apr 2015 09:09:57 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so184305277qkg.1 for <tls@ietf.org>; Mon, 20 Apr 2015 09:09:56 -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:date :message-id:subject:from:to:cc:content-type; bh=8zdb/LtMhFL8yBNoXRskt0oM1xijecogqHJygAqYbDc=; b=CRjGN/QhbRoriJDx6OgUfLKQMoDHsQrBcMEvE8xYxMzeLu2BSQM6U8hA5KA1c+PZMD Vzb1qR/8zMLQUQodb4REw39RVGQoU+5t0e0TdRWdE+yL/UeMY0LDimyFdTkLbxBFVZDy OsLYuJUXoc3C/VtjguCZD6D7NX1djme0ciNGSyAycNVyiLWurmkJXDFcVoBWPeGCig3V i/K0O9szjMM8FXAeCr2++WSS+4AeabCqmiNMxLuu581FVHFyOHlcrhjI+jcvoRZClJ+F NbdxTTg1qTYP0ZCPG9iGXFKd+5hHbJUticEn6Oy03Rlw7Lr4NyyGzpyykOgsLF5YdRSD gSQA==
X-Gm-Message-State: ALoCoQmPRHxBFADkJ6QnJSC1ZwLuTUL8NIifBRsIFjNLtZEpz4H5v4W/dS/CFr6nuG+KM0ZP1miL
MIME-Version: 1.0
X-Received: by 10.229.193.69 with SMTP id dt5mr4452187qcb.3.1429546196452; Mon, 20 Apr 2015 09:09:56 -0700 (PDT)
Received: by 10.140.80.165 with HTTP; Mon, 20 Apr 2015 09:09:56 -0700 (PDT)
X-Originating-IP: [172.56.3.80]
In-Reply-To: <20150420064243.GA7322@LK-Perkele-VII>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII>
Date: Mon, 20 Apr 2015 12:09:56 -0400
Message-ID: <CANeU+ZAL6oT6tP7OcL_8j6kp4oZB9V89R-0PrCdv-N27qVb0HQ@mail.gmail.com>
From: "StJohns, Michael" <msj@nthpermutation.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=001a11c24efe3ae11505142a2954
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/e1Fb_X9JytfyTShgOfuT5xzq-Y8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] HSM-friendly Key Computation
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: <http://www.ietf.org/mail-archive/web/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 Apr 2015 16:09:59 -0000

On Monday, April 20, 2015, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
wrote:

> On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote:
> >
> > What I would love to see for TLS1.3 is NO TLS specific mechanisms being
> > added to PKCS11.    That if we still sign the finished message, we use a
> > true MAC function.  That if we derive keys, we use a bog standard KDF.
> That
> > we stomp on every TLS specific twist unless there is a specific security
> > need to keep TLS secure.
>
> Not possible. There are features (e.g. extractor and resumption/unique
> interaction) that can't be feasibly removed (or even deprecated) and which
> need PRF'ing secret keys into public data.
>
> Also, true MAC functions just aren't enough for some places (such as
> deriving the various master secrets or unique value).
>
>
>

I'm not quite sure how you've come to this conclusion.  The underlying
function for a KDF is generally a MAC function which by definition produces
public data.  It's only when bound into a KDF that it by definition
produces secret data.  The main problem we've encountered is that we use
the same key to produce public (IV) data and private key material.   Fixing
this is more an issue of how to cryptographically isolate products of the
diverse operations in a way that enhances security.

Replacing the current functions with off the shelf ones along with a few
tweaks to the key derivation mixins and key tree can be done without
removing any functionality.

Mike

>
> -Ilari
>