Re: ACTION-84: Finishing support for key derivation/key agreement

Do we really see MQV or HMQV being useful - especially given both
their patent and security issues?

On Mon, May 20, 2013 at 4:06 PM, Acar, Tolga <tolga.acar@intel.com> wrote:
> Ah, that clarifies it for me - agreed.
> I think it would be helpful to give sample code for DH-basic (unauthenticated DH), MQV, and HMQV - in ECC or in FFC fields.
>
> - Tolga
>
>> -----Original Message-----
>> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
>> Sent: Monday, May 20, 2013 3:43 PM
>> To: Acar, Tolga; Ryan Sleevi
>> Cc: public-webcrypto@w3.org; Jim Schaad; Richard Barnes
>> Subject: RE: ACTION-84: Finishing support for key derivation/key agreement
>>
>> OK, I see where the confusion comes from now.
>>
>> I'm basing my terminology on the use cases earlier in my email. In other
>> words, when I say "ephemeral key" I mean the secondary key that one
>> would use in DH or MQV. I realize that the "primary key" which I refer to as
>> "static key" can sometimes be an ephemeral key (just as sometimes the
>> secondary key can be a static key) but I was hoping not to get into that
>> distinction here.
>>
>> So, stated in less ambiguous language:
>>
>> - DH case 1: myPrivateKey = my primary key, peerPublicKey = peer's primary
>> key
>> - DH case 2: myPrivateKey = my primary key, peerPublicKey = peer's primary
>> key, alg parameters contain my secondary private key and peer's secondary
>> public key
>> - MQV: myPrivateKey = my primary key, peerPublicKey = peer's primary key,
>> alg parameters contain my secondary key pair and peer's secondary public
>> key
>>
>> -----Original Message-----
>> From: Acar, Tolga [mailto:tolga.acar@intel.com]
>> Sent: Monday, May 20, 2013 3:33 PM
>> To: Ryan Sleevi
>> Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Jim Schaad; Richard Barnes
>> Subject: RE: ACTION-84: Finishing support for key derivation/key agreement
>>
>>
>>
>> > -----Original Message-----
>> > From: Ryan Sleevi [mailto:sleevi@google.com]
>> > Sent: Monday, May 20, 2013 2:52 PM
>> > To: Acar, Tolga
>> > Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Jim Schaad; Richard
>> > Barnes
>> > Subject: Re: ACTION-84: Finishing support for key derivation/key
>> > agreement
>> >
>> > On Mon, May 20, 2013 at 2:12 PM, Acar, Tolga <tolga.acar@intel.com>
>> wrote:
>> > > Thanks, Vijay - inline.
>> > >
>> > >> -----Original Message-----
>> > >> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
>> > >> Sent: Monday, May 20, 2013 12:11 PM
>> > >> To: Acar, Tolga; public-webcrypto@w3.org
>> > >> Cc: Jim Schaad; Richard Barnes
>> > >> Subject: RE: ACTION-84: Finishing support for key derivation/key
>> > >> agreement
>> > >>
>> > >> [Acar, Tolga] What is the advantage of putting ephemeral keys in
>> > >> algorithm parameters instead of using importKey to create a key
>> > >> object from an ephemeral key (or keys in plural), and passing the
>> > >> key
>> > >> object(s) as the first and/or second parameter to this call? The
>> > >> importKey approach seems to create a simpler interface and
>> > >> implementation, since an implementation would have only one place
>> > >> to
>> > look for keys.
>> > >>
>> > >> Sorry, I realize now that the text was ambiguous. The idea is to
>> > >> have these ephemeral keys passed as Key objects, not as byte
>> > >> arrays. So the discussion boils down to whether they are passed as
>> > >> top-level parameters to the function, or as algorithm-specific
>> > >> parameters in a dictionary. If we agree that this is the issue, I'm
>> > >> happy to have the
>> > discussion on where this should go.
>> > > [Acar, Tolga] Yeah, I'd prefer as top-level arguments for keys
>> > > instead of
>> > passing them in the algorithm parameters.
>> >
>> > I'm not really sure this is good/idiomatic JS. So far, the API has
>> > attempted that everything that is consistent for all
>> > operations/algorithms gets passed as a 'top-level' argument, whereas
>> > context-dependent parameters are passed in the dictionaries.
>> >
>> > I'm inclined to agree with the text as written - keeping them
>> > separate, rather than putting them as optional parameters.
>> >
>> > Could you explain more you're thinking on this?
>> [Acar, Tolga] From where I sit, you and I seem to agree. Let me clarify first,
>> and let me know if you think we are not on the same page after my
>> explanation below.
>>
>> This is one of the API suggestions from Vijay's e-mail.
>> > >> > KeyOperation secretAgreement(Key myPrivateKey, Key
>> peerPublicKey,
>> > >> > AlgorithmIdentifier agreementAlgorithm, AlgorithmIdentifier
>> > >> > derivationAlgorithm);
>>
>> I am suggesting that the private key object is always supplied as the first
>> argument named "myPrivateKey", the public key is always supplied in the
>> second argument named "peerPublicKey" to the secretAgreement()
>> function. The text as written told me otherwise (I passed the partial text
>> below for convenience). In particular, the text says that ephemeral keys
>> (which I interpret as public and private keys) are supplied in the parameters
>> of the "agreementAlgorithm" parameter. The last sentence is where I
>> disagree: I'm suggesting that the public and private keys are always supplied
>> in the first function argument (myPrivateKey) and the second argument
>> (peerPublicKey) to the secretAgrement() function. Vijay's answer seems to
>> agree with my suggestion, and so does your argument above on 'top-level'
>> arguments.
>>
>> > >> > for derivationAlgorithm. Ephemeral keys and key pairs are
>> > >> > supplied as parameters to the agreementAlgorithm (subject to
>> ACTION-83).
>>
>> Thus, I am suggesting that the last sentence in the text above is replaced
>> with the following: "Private and public keys, regardless of their ephemeral or
>> static status, are always supplied in the first and the second arguments to the
>> secretAgreement() function, respectively."
>>
>> >
>> > >
>> > >>
>> > >> [Acar, Tolga] I'd ask what I think the obvious question is. Why not
>> > >> call deriveKey + exportKey with the output key length as an
>> > >> algorithm parameter?
>> > >>
>> > >> Because the maximum number of bytes supported by that approach is
>> > >> limited by the biggest key size supported in the implementation.
>> > >> Also once you do a deriveKey with a particular algorithm, you may
>> > >> have modified the output of the KDF to fit the structure of that
>> > >> algorithm's keys (e.g. DES and parity bits).
>> > > [Acar, Tolga] Got it, sounds good.
>> > > Another supportive statement: It seems to me that deriveBytes()
>> > combined with importKey() would also allow daisy-chained KDF calls. I
>> > think that is also helpful.
>> >
>> > Agreed.
>> >
>> > >
>> > >>
>> > >> -----Original Message-----
>> > >> From: Acar, Tolga [mailto:tolga.acar@intel.com]
>> > >> Sent: Monday, May 20, 2013 11:19 AM
>> > >> To: Vijay Bharadwaj; public-webcrypto@w3.org
>> > >> Cc: Jim Schaad; Richard Barnes
>> > >> Subject: RE: ACTION-84: Finishing support for key derivation/key
>> > >> agreement
>> > >>
>> > >>
>> > >>
>> > >> > -----Original Message-----
>> > >> > From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
>> > >> > Sent: Sunday, May 19, 2013 11:44 PM
>> > >> > To: public-webcrypto@w3.org
>> > >> > Cc: Jim Schaad; Richard Barnes
>> > >> > Subject: ACTION-84: Finishing support for key derivation/key
>> > >> > agreement
>> > >> >
>> > >> > We had a call on this last Monday, and it looks like we have an
>> > >> > initial proposal that would benefit from wider WG discussion. A
>> > >> > summary of this proposal follows. Feedback is welcome.
>> > >> >
>> > >> > Goals and non-goals:
>> > >> > - We want to support at least DH and MQV primitives over finite
>> > >> > fields and elliptic curves. This is likely > 90% of the usage for
>> > >> > the foreseeable
>> > >> future.
>> > >> > - Supporting multi-party protocols, while nice in theory, adds
>> > >> > complexity for not-big-enough gain. There are a large number of
>> > >> > multiparty contributory key agreement schemes, none of which are
>> > >> > widely
>> > >> used in practice.
>> > >> [Acar, Tolga] +1
>> > >>
>> > >> > - It is not necessary to support key confirmation schemes
>> > >> > directly in the
>> > >> API.
>> > >> > We will simply provide enough access to the shared secret to
>> > >> > allow key confirmations schemes to be added on top of the API.
>> > >> > - There are likely going to be applications of KDF where you want
>> > >> > to generate more bytes than the biggest key size supported by an
>> > >> implementation.
>> > >> > However, we don't have to support streaming derivation - i.e.
>> > >> > something where the caller does not know how many bytes they
>> want
>> > >> > up
>> > >> front.
>> > >> > - Method names are cheap, but vendors hate to add lots of new ones.
>> > >> >
>> > >> > In particular, our low-level API should be able to support at
>> > >> > least the following key agreement schemes. For each scheme, I
>> > >> > have listed the parameters that each party needs:
>> > >> > - Basic DH: Own private key, peer's public key.
>> > >> > - Full DH: Own static private key, own ephemeral private key,
>> > >> > peer's static public key, peer's ephemeral public key.
>> > >> > - Full MQV: Own static private key, peer's static public key, own
>> > >> > ephemeral key pair, peer's ephemeral public key.
>> > >> >
>> > >> > So with those considerations in mind, we would like to propose
>> > >> > the following
>> > >> > changes:
>> > >> >
>> > >> > 1. New method added to Crypto interface to support secret
>> agreement:
>> > >> >
>> > >> > KeyOperation secretAgreement(Key myPrivateKey, Key
>> peerPublicKey,
>> > >> > AlgorithmIdentifier agreementAlgorithm, AlgorithmIdentifier
>> > >> > derivationAlgorithm);
>> > >> >
>> > >> > The result from the KeyOperation is a non-extractable Key object
>> > >> > for derivationAlgorithm. Ephemeral keys and key pairs are
>> > >> > supplied as parameters to the agreementAlgorithm (subject to
>> ACTION-83).
>> > >> [Acar, Tolga] What is the advantage of putting ephemeral keys in
>> > >> algorithm parameters instead of using importKey to create a key
>> > >> object from an ephemeral key (or keys in plural), and passing the
>> > >> key
>> > >> object(s) as the first and/or second parameter to this call? The
>> > >> importKey approach seems to create a simpler interface and
>> > >> implementation, since an implementation would have only one place
>> > >> to
>> > look for keys.
>> > >>
>> > >> >
>> > >> > Note that as a result of this, DH and ECDH algorithms will no
>> > >> > longer support deriveKey. This support will be provided instead
>> > >> > by the key derivation algorithms. This should simplify Section 19
>> > >> > (algorithm support) a
>> > >> little bit.
>> > >> >
>> > >> >
>> > >> > 2. New method added to Crypto interface to output bytes from a
>> > >> > KDF instead of a key object (since people derive IVs, nonces,
>> > >> > etc. also using
>> > >> > KDFs):
>> > >> >
>> > >> > KeyOperation deriveBytes(AlgorithmIdentifier kdfAlgorithm, Key
>> > >> > baseKey, int bytes)
>> > >> >
>> > >> > This operation is supported by all keys that support deriveKey.
>> > >> > The result of the KeyOperation is an ArrayBufferView with the
>> > >> > given number of bytes derived from the baseKey. This is exactly
>> > >> > the same as deriveKey except for the parameters dealing with
>> > >> > specifying the target
>> > >> key.
>> > >> [Acar, Tolga] I'd ask what I think the obvious question is. Why not
>> > >> call deriveKey + exportKey with the output key length as an
>> > >> algorithm parameter?
>> > >>
>> > >> >
>> > >> >
>> > >> > 3. (from Richard) Possibly extend deriveKey and the above
>> > >> > definition of deriveBytes so they can slice the output.
>> > >> >
>> > >> > Richard's use case for this is as follows: say a protocol wants
>> > >> > to derive two AES keys and two IVs from a secret using a KDF.
>> > >> > Then, the application could use the slice parameters to get the
>> > >> > IVs from the KDF while ensuring that it was never directly
>> > >> > exposed to the key material of the
>> > >> AES keys.
>> > >> >
>> > >> > We did not reach consensus on this item during the call, but
>> > >> > Richard said he would send out a more fleshed-out proposal on
>> > >> > this
>> > aspect.
>> > >> >
>> > >> >
>> > >> > Please let us know if you have any comments, positive or negative.
>> > Thanks!
>> > >> >
>> > >> > -Richard, Jim and Vijay
>> > >
>> > >
>

Received on Monday, 20 May 2013 23:31:18 UTC