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

Messieurs,
Do you think that a live session, with a dedicated conf call, could help to make a status on what is a consensus, what is the disagreement ?
Regards,
Virginie


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: mercredi 24 juillet 2013 00:48
To: Jim Schaad
Cc: Jim Schaad; 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 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 Wednesday, 24 July 2013 15:57:03 UTC