Re: [TLS] HSM-friendly Key Computation

Eric Rescorla <ekr@rtfm.com> Wed, 22 April 2015 23:03 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 154FE1B2CD1 for <tls@ietfa.amsl.com>; Wed, 22 Apr 2015 16:03:50 -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 bz5mFWrt7sND for <tls@ietfa.amsl.com>; Wed, 22 Apr 2015 16:03:47 -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 17E141B2C8C for <tls@ietf.org>; Wed, 22 Apr 2015 16:03:47 -0700 (PDT)
Received: by wiun10 with SMTP id n10so73915466wiu.1 for <tls@ietf.org>; Wed, 22 Apr 2015 16:03:45 -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=nhuEiLV/I8BfdUbGXN5GYcUE5WRVqC0aKG1Ig8cYIjI=; b=gy053F/CvwiMyOEj5UosA2AL8xOgVpAikd90iolNQmPw+BShEZxWgl+8STaSbbwytC 8qP41pMVnAYHIHEJgI74qtJ1XsMFPVE6h2JgFDZeoCwPE4LNVnzz3BYMyE1UdhgTgkPF 1JQ7072BlvicyyaBCuoqqOW2HsfO6C0EvP0pMYQDS0LEAHiHiMZ4Y2Ls0dirvXN9kZ97 Bj/WtxmmdoVEim9ECC3Ggw2MPOcfVGyHp6zfZ/AJWlx3kvKF5ioz4N9kV2AOXpaE0h+L NCsexHih8cOPIsKC3XtwYc0J0fq/tQEk/p7hFnKCp9oHFhJydxlv/LOd+iHRNOnmNj5G rnMg==
X-Gm-Message-State: ALoCoQmnimRKteXMw+5gmifJs1pOUlKH8hBXjggOofjatL3NBjWjGyfZjUYp+PCJdPJQkw4TKVDM
X-Received: by 10.180.84.67 with SMTP id w3mr660022wiy.68.1429743825833; Wed, 22 Apr 2015 16:03:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.87 with HTTP; Wed, 22 Apr 2015 16:03:05 -0700 (PDT)
In-Reply-To: <55381302.5030307@nthpermutation.com>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <CANeU+ZAL6oT6tP7OcL_8j6kp4oZB9V89R-0PrCdv-N27qVb0HQ@mail.gmail.com> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <CABcZeBPN33DM_C0sAmCTFCTdNrcQ7y7eEBcZgPe+2f1EaxtXzA@mail.gmail.com> <55381302.5030307@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 22 Apr 2015 19:03:05 -0400
Message-ID: <CABcZeBN1W-KyNnPd9qU9dFP3dG8E=F1hOyK1NoeH-tsQT8XrFw@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=f46d04440276dbe3810514582cbf
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WONIZV2AuaebBMVs5QjyKmfGlX4>
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: Wed, 22 Apr 2015 23:03:50 -0000

On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <msj@nthpermutation.com>
wrote:

>  On 4/22/2015 1:37 PM, Eric Rescorla wrote:
>
> If we're using HKDF-Extract, can we just key off different labels?
>
>  -Ekr
>
>
Sorry, read that as "HKD-Expand".

-Ekr


> Basically, no.
>
> The Extract function is really not designed to be used standalone but as a
> way of concentrating entropy for input to the expansion phase.  Its
> dangerous to talk of these functions as separately callable.  They are
> steps not separate functions.
>
>  The extract step's only non-key input - salt - is not the same as the
> "info" input used in the expand phase - 'salt' is supposed to be missing or
> random,  not a fixed string like a label.
>
> "info" is where the various labels go and that's only present in the
> expand phase.
>
>
> What you want to do is specify as part of the mixins (e.g. 'info' - e.g.
> the collection of label and context)  a set of fields that describe 1) how
> the key stream is going to be broken up (eg. lengths of the sub keys), 2)
> what algorithms will use each of the parts of the key stream, and 3)
> whether or not those parts are allowed to be exported/extracted.
>
> A software module will basically ignore these because - really - its all
> the same memory although it should really make sure the key lengths and
> types matc.  An HSM will look at these and be able to make policy decisions
> for protection of the segments (e.g. preventing export of material that was
> created to be non-exportable).
>
> Having all of these in the mixins means that the key stream expansion
> completely changes if ANY of these mixins change which in turn means  that
> the various ways you can use to extract truly secret key material (as
> differentiated from exportable material) from an HSM using the currently
> defined mechanism can be eliminated.  (I can explain my reasoning if
> necessary).
>
>
> Mike
>
>
>
>
> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
>
>> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
>> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
>> > >
>> > >There are other places in TLS that fundamentally need to (indirectly)
>> derive
>> > >public data out of secret key material.
>> > That's not a a problem. The problem is using the same mechanism to
>> derive
>> > the public data that we use to derive the keys.
>> > It's even OK to use the same secret key for both (from an HSM POV).
>> >
>> > What Michael is saying is that there are existing functions for both KDF
>> > (secret material -> key) and Mac (secret material-> unique public data).
>> > He's requesting that TLS not have it's own versions of these functions.
>>
>> So would using two different PRF functions, one for parts that don't
>> downgrade and another for parts that do downgrade (e.g. IV derivation,
>> unique / finished calculations, exporter calculations, etc..) solve the
>> issue?
>>
>> (Of course, the two functions should be closely related, so not to
>> annoy software implementations too much)...
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>
> _______________________________________________
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>