Re: What happended to SecretAgreee?

Ryan,

I think, to be fair, there are three categories of things in the 'useful
and technically possible' category:
(A) Those that are generally safe
(B) Those that might be safe if used properly, but which can also be used
badly and cause problems
(C) Those that are never safe

We know that subtlecrypto (which is still a bad name) contains enough rope
for people to hang themselves (B) but we could shy away from things which
are outright already-lit explosives (C).

It's clear to me why you might want to access the shared secret output of
DH directly - there's any number of KDFs you might want to implement
yourself. I don't want to put words into Jim's mouth, but I think his
argument is that directly mapping to an AES key, say, is in category (C).

You're right that this doesn't help with the specification, though, so I'll
go ahead and implement the proposal for obtaining the derived key length
before doing the derivation, unless you have any issues with that.

...Mark




On Thu, Feb 27, 2014 at 3:21 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Thu, Feb 27, 2014 at 3:11 PM, Jim Schaad <ietf@augustcellars.com>wrote:
>
>> Ryan,
>>
>> If you want to look at some of the deeper security requirements.
>>
>>
>> http://r.duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fwww.iacr.org%2Fconferences%2Feurocrypt2004%2Fslides%2Fsession10talk3.ppt
>>
>> contains one argument over why a KDF function is needed and you cannot
>> use ZZ directly as keying material.  Given that one cannot assume that ZZ
>> is uniform, since not all values are possible, directly using ZZ as keying
>> material is a security attack point.
>>
>> This means that my argument is MUST not SHOULD.
>>
>> Jim
>>
>
> I fear you have misunderstood me, and saw the "RFC" ness of the
> capitalization rather than the intended emphasis.
>
> Let me phrase it differently:
>
> There are two things under discussion:
> 1) Whether something is technically possible
> 2) Whether something is good security practice
>
> There is a reason this is called SubtleCrypto - there are subtleties here.
>
> You originally argued that there is no legitimate reason to want ZZ - as a
> Key or as Bits. To this point, you're mistaken. We've discussed since the
> beginning why you would want this.
>
> The next question is - even if there is legitimate reason, should we allow
> it. This is the same discussion about "raw" AES, the same discussion about
> MD5, the same discussion about 3DES, the same discussion about CFB8, etc.
>
> It seems to me that your argument is "We shouldn't allow X because X is
> hard to get right", but for every other value of X != "diffie-hellman phase
> 2", we've said "That's why this is called SubtleCrypto".
>
> I don't see how the reference materially changes that discussion, or that
> there are legitimate use cases.
>
>
>>
>>
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Thursday, February 27, 2014 2:07 PM
>> To: Jim Schaad
>> Cc: public-webcrypto@w3.org
>> Subject: Re: What happended to SecretAgreee?
>>
>>
>>
>> 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.
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>