Re: ACTION-84: Finishing support for key derivation/key agreement (take 2)

On Tue, Jul 23, 2013 at 3:23 PM, Jim Schaad <ietf@augutscellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Tuesday, July 23, 2013 1:52 PM
>> To: Jim Schaad
>> Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Richard Barnes; Israel
> Hilerio
>> Subject: Re: ACTION-84: Finishing support for key derivation/key agreement
>> (take 2)
>>
>> On Tue, Jul 23, 2013 at 1:49 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Ryan Sleevi [mailto:sleevi@google.com]
>> >> Sent: Monday, July 22, 2013 3:58 PM
>> >> To: Jim Schaad
>> >> Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Richard Barnes; Israel
>> > Hilerio
>> >> Subject: Re: ACTION-84: Finishing support for key derivation/key
>> >> agreement (take 2)
>> >>
>> >> On Mon, Jul 22, 2013 at 3:41 PM, Jim Schaad <ietf@augustcellars.com>
>> >> wrote:
>> >> >
>> >> >
>> >>
>> >> Correct - but it was based on a misunderstanding of Vijay's proposal.
>> >>
>> >> I understood the original proposal was that Z would be fed directly
>> >> into
>> > the
>> >> KDF, and the key returned was the derived key. However, after reading
>> >> this again, I see that the Key returned wraps Z as a 'raw'
>> >> key.
>> >>
>> >> So the only issue here is that the algorithm (derivationAlgorithm)
>> >> may be something being polyfilled - in which case, a native
>> >> implementation cannot execute the algorithm normalization parameters
>> >> or handle it for a
>> > polyfilled
>> >> case.
>> >>
>> >> Normally, a JS application would use any of the ES5/ES6 methods
>> >> available
>> > to
>> >> intercept and/or wrap window.crypto.subtle's prototype with its own
>> >> extensions. However, in this case, it can't intercept the derivedKey
>> > algorithm.
>> >>
>> >> However, this issue exists in the current ED as well - the
>> > derivedAlgorithm
>> >> parameter (which isn't even specified fully - oops!) has the same
> issues.
>> >>
>> >> Off the top of my head (eg: not having fully considered the
>> >> implementation complexities/realities), I can see a couple solutions,
>> >> but they all feel a
>> > bit
>> >> gross:
>> >> - Expose a meta 'raw' algorithm to allow a Key object to be created
>> >> that
>> > can
>> >> then be exported
>> >> - Expose a meta 'raw' KDF, for which deriveBits() just exposes the
>> >> key
>> > bits
>> >> - Expose some 'secret agree bits' function
>> >>
>> >> Of this, I'm inclined to go for a 'raw' KDF, but if anyone else has
>> >> better suggestions, I'm all for it.
>> >
>> > I can think of one other way to handle this which would address some
>> > other
>> > problems:
>> >
>> > Make the crypto interface read-only
>> > Add a new function to allow for adding a new crypto algorithm which
>> > contains a name and a set of functions for implementing the different
>> routines.
>> >
>> > The environment can then make the calls back into JavaScript for those
>> > algorithms which are implemented there and stay in the browser for its
>> > own implementations.
>> >
>> > Algorithms could then define additional things to put into the
>> > definition structure.  As an example RSA signature algoirthms could
>> > say that if you place and oid field in the definition, a newly defined
>> > hash algorithm could be used in RSA v1.5 signatures  (If implemented and
>> permitted by the
>> > environment.)   This would allow for newly defined hash algorithms to be
>> > used in a number of different places without any new problems.
>> >
>> > Jim
>>
>> This was considered early on and is highly inconsistent with the web
> platform
>> and with general ES5/6 design.
>
> Ok - you have just basically said you don't care about this issue when
> dealing with hash functions.  Tell me why I  should care about it for KDF
> functions?
>
>

That's not at all what I said.

As was discussed previously, the example you gave - such as the RSA
signature - has several different options that require no changes to
the API/function signatures - and thus are not comparable to the KDF
issue.

For example, a new method where the params effectively specify
DigestInfo for the RSA case. Alternatively, a 'raw' RSA sign
operation.

However, I'll help you out further, and point out counter-examples -
for example, HMAC (or, even further in the case of KDFs, algs like
HKDF), which are composed of hash functions where a DigestInfo-like
solution is not applicable. I'll readily agree it's not a
one-size-fits-all solution.

But in the case of such widely used agreement schemes like DH/ECDH,
where we know there's a clear desire to support a variety of protocols
- whether OTP, ZRTP, or others - it seems highly ill-informed to not
consider the case.

>From our very first discussions, we considered the case of whether or
not to do an 'object oriented' API - for example, an AES object that
is composed with a Block Mode object, or an HMAC object that is
composed with a Hash object - and that was quickly ruled out for the
significant complexity and operational overhead, not to mention that
from an implementation side, it's unlikely to meet many (any?) of the
stated goals.

// For reference, the OO strawman that doesn't really work, nor does
it match the platform or the language
interface hash {
  readonly attribute DOMString registeredName;
  readonly attribute DOMString oid;

  Future<ArrayBuffer> hash(CryptoOperationData data);
  Stream hashStream(Stream input);
};

The reason it doesn't work is simple - the platform object vs user
object distinction that's core to the platform. See
http://dev.w3.org/2006/webapi/WebIDL/#dfn-platform-object ,
http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-interface , and
http://dev.w3.org/2006/webapi/WebIDL/#dfn-consequential-interfaces

That is, it means every operation would have to support two possible
inputs - a platform object (implementing an interface) or a user
object (implementing a callback interface), and would have to
distinguish between them. Further see the requirements and limitations
on callback interfaces on this.

So now that I've recapped the discussion about why this doesn't work
(rather than a summary "Since you don't care"), can we discuss further
about the issue at hand and the limitations of the proposed KDF API?

Received on Tuesday, 23 July 2013 22:48:52 UTC