RE: What happended to SecretAgreee?

On Feb 27, 2014 7:33 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
>
>
>
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Thursday, February 27, 2014 6:11 PM
> To: Jim Schaad
> Cc: public-webcrypto@w3.org
> Subject: RE: What happended to SecretAgreee?
>
>
> On Feb 27, 2014 5:58 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> >
> >
> >
> > From: Ryan Sleevi [mailto:sleevi@google.com]
> > Sent: Thursday, February 27, 2014 3:22 PM
> > To: Jim Schaad
> > Cc: public-webcrypto@w3.org
> > Subject: Re: What happended to SecretAgreee?
> >
> >
> >
> > 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.
> >
> > [JLS] Other than as an input to a KDF function, the above statement is
completely correct.  There is no legitimate reason to get ZZ.  I would far
rather expose ZZ by the following steps than by the use of deriveBits - Run
a secretAgreement on the DH keys to get a KDF key, then run export on the
KDF key to get ZZ.   This allows you to get to ZZ for use in a polyFill KDF.
>
> Did you mean to say incorrect? Your statements here are in conflict.
> [JLS] That is only true if you believe that secretAgreement and
deriveBits are in some way the same thing.  I don't agree with that..  I
agree there is reason to want ZZ as a secret - not s bits.
>

They are the same.

There is no legitimate reason - at an API level - to prevent polyfills or
make them arbitrarily complicated.

> Applications have a legitimate need for ZZ, and not solely as an input to
a WebCrypto KDF.
> [JLS] I know of none, zero, nada except as an input to a KDF function.
 However, I provided a way to get to the value of ZZ in that case by
exporting from a KDF function.
>

It makes no sense, as a developer or implementer, to arbitrarily fragment
like that.

We MUST support polyfilled KDFs. That's nonnegotiable, because it's such a
basic tenet of _all_ of the API here.

Your proposal simply adds more speedbumps - unnecessarily. DeriveBits is
nothing more than "secretAgreement+export", as a single API. Why complicate
things, since it adds no security and still be as misused as you fear?

> We MUST support that.
> We MUST NOT introduce arbitrary API "speed bumps".
> We MUST provide a consistent API pattern - whether you're talking DH,
ECDH, HDKF, or (insert alg foo) here
> deriveKey and deriveBits (not secretAgreement - that issue has long been
closed in favour of deriveKey) fundamentally provide that.
> I do not believe the added complexity - for authors or for implementers -
of introducing "confounding" steps by requiring new intermediate KDFs
provides any real security, and it seems like that's the only argument for
making a change.
> You now seem to be fundamentally arguing against deriveBits as a concept
entirely, and that makes no sense to me.
> Perhaps, rather than short snippets of an emerging design that does not
seem fully ready, you can make a concrete proposal of your solution - that
so far seems to be removing deriveBits entirely, removing deriveKey,
introducing secretAgreement, and restricting the algorithms that can be
used both as inputs and outputs of this function, along with clear
statements of the problems you are trying to solve. I feel its the only way
for others - and myself - to actually understand where your concerns really
lie.
> [JLS]  I am not against deriveBits.  I accept it as a reasonable thing to
have.
> I would say the following:
> 1.  Add the secretAgreement function to the interface and enable it for
all key agreement algorithms
> 2.  Keep deriveKey and deriveBits, but only enable them on KDF algorithms
> 3.  remove deriveKey and deriveBits from all key agreement algorithms
>
>

That is not acceptable because it fails to address the use cases that we
wish to support, as I have already explained.

> >
> > 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
> >
> >
> >
> >
> >
> >
>