Re: What happended to SecretAgreee?

On Thu, Feb 27, 2014 at 2:35 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Thu, Feb 27, 2014 at 2:07 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>>
>>
>> On Thu, Feb 27, 2014 at 1:14 PM, Jim Schaad <ietf@augustcellars.com>wrote:
>>
>>> I do not believe that one can ever go directly from the ZZ value to  a
>>> symmetric key for AES-CBC.  This is just really bad security behavior for
>>> any number of reasons.  However this seems to be what is being proposed on
>>> some level by the current discussion.
>>>
>>
>> Ok, let's unpack what you said here. One certainly can. Your argument is
>> whether you SHOULD. That's entirely different discussion.
>>
>
> It's a good and timely one, though.
>
> If the only derived key algorithms allowed with (EC)DH were the KDFs, this
> would simplify the specification considerably. I've been drafting the text
> that allows an AES key, etc., to be derived directly from the DH secret
> value (by truncation) and we have to jump through several hoops for that
> (mainly to derive the length to which the shared secret should be
> truncated, since this derivation is dependent on the target algorithm).
>

How so? You still have to specify the length with the KDFs.


>
> If it is bad practice to go directly from the secret value to an AES key
> (say), I would argue that we should not support that as a first class
> operation. If you really want to do it you can deriveBits on the DH key and
> then import those as "raw" AES bits.
>
> ...Mark
>
>
>>
>>
>>>
>>> This means that no, I do not believe that DH is ever a key derivation
>>> algorithm under any circumstances.   It is a method com computing a shared
>>> secret.  From that shared secret one can then apply a key derivation
>>> algorithm (identity is not one) to get a key for some other purpose.  There
>>> is no reason to believe that any sub-portion of ZZ is not biased.  That is
>>> the reason for doing the PRF on it.
>>
>>
>>> The entire concept of doing a deriveBits direction from the algorithm DH
>>> therefore makes absolutely no sense to me.  There is no KDF function that
>>> is being applied to ZZ to get the bits you want as output.
>>>
>>
>> It's quite simple (and has been made clear since the very first time we
>> talked about DH). How "ZZ" is used can vary depending on what protocol
>> you're using - some use it with protocol-specific KDFs.
>>
>> Or you're polyfilling your own KDF that requires ZZ.
>>
>>
>>>
>>> I would also expect that in terms of extractability, if the private key
>>> is marked as not extractable, then ZZ and any portion of ZZ is also marked
>>> as being not extractible.  This would be passed on to the KDF function.  It
>>> would also mean that deriveBits could never work on such a function since
>>> it would export part of the computed shared secret.
>>>
>>> The reason that I put the "and maybe a new key derivation algorithm" in
>>> parentheticals is because I am not sure that I believe that it needs to be
>>> supported t the current time by the WebCrypto specification.  This is not
>>> uncommon practice that one generates a Master Secret key from a shared
>>> secret, and then uses that key value to generate other shared secret keys
>>> that are used for specific purposes.  One example would be to have a
>>> different MAC key for I send to you from you send to me.
>>>
>>>
>> If you don't want to allow that, don't support the deriveBits operation.
>> I don't see where the angst is.
>>
>> On a technical level, there are use cases for it. On a technical level,
>> the API supports it.
>>
>> It seems your entire argument is that you don't like it? I'm not trying
>> to be dismissive, I'm trying to make a clear distinction between "can" and
>> "should", so that we can make sure the "can" is correct BEFORE discussing
>> the "should".
>>
>>
>>
>>>
>>>
>>>
>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> Sent: Thursday, February 27, 2014 12:26 PM
>>> To: Jim Schaad
>>> Cc: public-webcrypto@w3.org
>>> Subject: Re: What happended to SecretAgreee?
>>>
>>> Yes, Key agreement algorithms (which DH Phase 2 is - agreement of the
>>> secret Z based on the exchanged parameters) is treated as a key derivation
>>> algorithm.
>>>
>>> Can you provide any examples of algorithms or parameters you do not
>>> believe fits into the deriveKey mechanism?
>>>
>>> I wasn't sure if your "and maybe a new key derivation algorithm"
>>> indicated a degree of uncertainty. If so, yes, that is exactly the workflow
>>> - for example, if you wanted to feed Z into HDKF to extract/expand.
>>>
>>> On Thu, Feb 27, 2014 at 12:21 PM, Jim Schaad <ietf@augustcellars.com>
>>> wrote:
>>> No, that is not true.
>>>
>>> secretAgreement when from a key agree algorithm to a key derivation
>>> algorithm
>>>
>>> deriveBits and deriveKey go from a key derivation algoritm to  either a
>>> byte array or a symmetric keying algorithm (or maybe a new key derivation
>>> algorithm)
>>>
>>> jim
>>>
>>>
>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> Sent: Thursday, February 27, 2014 12:05 PM
>>> To: Jim Schaad
>>> Cc: public-webcrypto@w3.org
>>> Subject: Re: What happended to SecretAgreee?
>>>
>>> The names were changed, but the behaviours the same.
>>>
>>> deriveBits and deriveKey.
>>>
>>> On Thu, Feb 27, 2014 at 12:00 PM, Jim Schaad <ietf@augustcellars.com>
>>> wrote:
>>> At one point, I thought there was an agreement to add a new function to
>>> the SubtleCrypto interface called secretAgreement.  This never happened.
>>>
>>> Was there a decision that I missed where this either was either not
>>> actually decided or was reversed?
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>
>