Re: [TLS] HSM-friendly Key Computation

Joseph Salowey <joe@salowey.net> Fri, 24 April 2015 17:13 UTC

Return-Path: <joe@salowey.net>
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 8D9031B37C2 for <tls@ietfa.amsl.com>; Fri, 24 Apr 2015 10:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 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, SPF_PASS=-0.001] 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 qhxhsohEms3P for <tls@ietfa.amsl.com>; Fri, 24 Apr 2015 10:13:25 -0700 (PDT)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.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 5CF001B37C8 for <tls@ietf.org>; Fri, 24 Apr 2015 10:13:25 -0700 (PDT)
Received: by qcrf4 with SMTP id f4so29188916qcr.0 for <tls@ietf.org>; Fri, 24 Apr 2015 10:13:24 -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=Qrz2ii5hrs/8KJe1NYyX2JuEBYpi/oM1V3o6TlMcmxk=; b=BKi/ZPcCnJKa8R2c9Rh81wrPpvLQkJLshin1HKW959DrOdfSu9k2FWotBCUg+nP/VY 7bz7dsM+OjPc7DMa/pSbiq2rkKyGbg9RefFmfml0eiXSPHr/pUaKguXpbmgJFwHP9IJz DcB25cznzfXNA1bBJKHP/F08sgy0geXcA+kPKhsFdJs6Md7U6b++6jJKgUHFqd2m2HOO r+pzFLagxM8eZbZaggWVC/3zAyoNsKKCX2crz18bPf5Ku3rlS5O6uV6MU1LUC5KU79fH VML3ICcunfCf3/1+3XMkqsmCXwEJrpK3AAT+M2edmB5fjUets5l4ZaEKXnoQFGcjKj5w OQDA==
X-Gm-Message-State: ALoCoQmZNZhArMMIh8JVLC3zw6SyEXQU/YMTusP5UvakfzCSngA/8kEca+ymc6dxOEoBcM2FSDe8
MIME-Version: 1.0
X-Received: by 10.55.21.93 with SMTP id f90mr17469297qkh.7.1429895604658; Fri, 24 Apr 2015 10:13:24 -0700 (PDT)
Received: by 10.96.121.104 with HTTP; Fri, 24 Apr 2015 10:13:24 -0700 (PDT)
X-Originating-IP: [2601:8:b300:a5:1443:ca81:e5b1:e93e]
In-Reply-To: <55394191.1050203@nthpermutation.com>
References: <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> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> <20150423175244.GA26942@LK-Perkele-VII> <55394191.1050203@nthpermutation.com>
Date: Fri, 24 Apr 2015 10:13:24 -0700
Message-ID: <CAOgPGoC4AcoQ1nSoqA20NSqnd1YXt=CTvLj2DVi6DXnxincJjg@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=001a1147efc894ef9505147b83b0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hMKRZEb1YieS6j0rr_5nRYVW5UM>
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: Fri, 24 Apr 2015 17:13:28 -0000

On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns <msj@nthpermutation.com>
wrote:

> On 4/23/2015 1:52 PM, Ilari Liusvaara wrote:
>
>> On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote:
>>
>>> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote:
>>>
>>>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:
>>>>
>>>> One possible structure in TLS notation:
>>>>
>>>> struct prf_output
>>>> {
>>>>       /*
>>>>       0x0000 => For key derivation
>>>>       0x0001 => For AEAD keying
>>>>       0x8002 => For AEAD IV
>>>>       0x8003 => For octet string (exporters, unique)
>>>>       */
>>>>       uint16 type;
>>>>       uint16 length;  /* In bytes. */
>>>> };
>>>>
>>> I ended up with a bit larger set of key types:
>>>
>>> Master Secret (can only be used with KDFs)
>>>
>> Right.
>>
>>  AES-CMAC
>>>
>> Not used anywhere (insufficient security).
>>
>
> For this and the comment below..... I'm not just thinking about TLS.  And
> I am thinking about how to retrofit this to TLS1.2 which doesn't require
> this to be an AEAD function.  And then there's the composed AEAD suites
> (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).   So while they
> may not be used by TLS directly, I want to get code points for all the
> possibilities.
>
>>
>>  AES-AEAD
>>>
>> Is there ment to be XXX-AEAD for different encryption algorithms?
>> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?
>>
>
> Generally yes for xxx-aead having different types per algorithm. Because
> you don't want to (for example) be able to use material for both AES and
> say GOST.   For modes, AEAD modes are mostly supersets or combinations of
> non-AEAD modes and there's an attempt to enforce "releasability only after
> verification" type policies on the CCM and GCM modes.   It would be good to
> have different codes for CCM and GCM (or even other modes), but I don't
> know that adds markedly to security.
>
>>
>>  AES-ENCRYPT
>>>
>> Not used. Encryption always pairs with authentication (AEAD).
>>
>
> See above - one of the questions is how does a composed AEAD suite derive
> subkeys.  Generically it seems to be "split the stream wherever you want"
> and as noted, that has a few problems.
>
>>
>>  HMAC-SHA1
>>>
>> A NULL cipher key? That one wouldn't be directly used for anything else.
>>
>
> For TLS1.2 and before, being able to tag that you're deriving an integrity
> key...  ditto for below.
>
>>
>>  HMAC-SHA2
>>>
>> NULL cipher keys are per algorithm?
>>
>>  GENERIC-DATA (different that PKCS11 generic secret - could be IV material
>>> for example).
>>>
>> This is "octet string" above (except IVs are "AEAD IV").
>>
>
> Not quite. (<begin pedantic mode>  :-) )
>
> One of the problems we have is a lack of common language.  And IV is one
> of those that's very slippery.
>
> TLS - incorrectly - called what's being produced by the master secret
> expansion an "IV".   What it actually was was the "first IV" of the session
> for cipher suites that included  CBC as a mode and a "session nonce" for
> suites with counter based ciphers.
>
> An IV is the common data injected by both sender and receiver to ensure
> that the same data doesn't encrypt the same way if identical data happens
> to occur in the plaintext stream multiple times.  For counter based
> ciphers, the IV is used with the block counter to form the block nonce(s)
> that (is/are) encrypted to form the XOR key stream.
>
> An counter-based IV  (e.g. for CTR, CCM and GCM) is generally composed of
> the concatenation of the session nonce (or as we've been discussing a fixed
> length of zeros) plus a per-message value (and we've been discussing always
> using the message sequence number as that per-message value).
>
> Due to the way TLS is constructed, what comes out of the master secret
> expansion can only be a "first IV" or a session nonce.  It would be
> possible to change this so an expansion is done with each message (e.g.
> same master secret, different mixins such as the sequence number) to
> generate a true per-message IV, but that's expensive and provides little
> security benefit.
>
> </pedantic mode>
>
>
>>  as a starting point.
>>>
>> Depending on view, you also need special type for exporter secret, since
>> it behaves somewhat unlike others.
>>
>
> I think the easiest way to accomplish this is to use a flag saying whether
> or not its exportable (generally removable from an HSM) that gets mixed
> in.  That way you have the common language of what you want to generate and
> then only have to decide on handling criteria.
>
>
[Joe] I've having trouble understanding what exactly you are designing
here, is it the interface to a specific HSM or is it the TLS 1.3 key
derivation or is it something else? I think we need to make sure that we
have the requirements defined for the TLS 1.3 key derivation.

Its not clear to me what the problem is with just including the context
label, session hash and possibly length.   The context label would
differentiate between derived key material for different purposes.  For
example, public and private data would use different context labels.  One
would also probably want to include the cipher suite ID in the context
label for keys derived for encryption.



>
>
>
>>  It turns out that you want to subdivide AES AEAD uses from non AEAD AES
>>> functions because you don't want to be able to use AES-CTR to get around
>>> the
>>> AES-CCM and GCM "don't let the data come out unless its been verified"
>>> policy.
>>>
>> As said, encryption always pairs with authentication.
>>
>>
>>
>> -Ilari
>>
>>
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>