Re: Key Agreement and Key Derivation Guidelines

Thanks Eric-- yes, saw the history with DH's removal, and also the GitHub issue for HKDF (including the migration to the IETF spec).

I think what I'm asking for is for those algorithms to be added to this list as well, so that it's clear that they're part of the suggested implementation:
https://w3c.github.io/webcrypto/Overview.html#algorithm-recommendations-implementers

I'm not sure if that's a substantive change from what the group intends.

Thanks,
Brad


On Jun 2, 2016, at 4:24 PM, Eric Roman <ericroman@google.com<mailto:ericroman@google.com>> wrote:

DH and Concat KDF were removed from the spec due to lack of implementation support (couldn't rely on it being supported across UAs).

The survivors were ECDH and HKDF.

Note that the spec doesn't currently describe "HKDF", but instead describes "HKDF-CTR" -- this is planned to change, per https://github.com/w3c/webcrypto/pull/16. In fact this naming is already the case in Chrome, and I believe also Firefox 47.

As far as why DH was shunned (by Chrome): I can't personally provide expert testimony, but will refer you to this thread: https://lists.w3.org/Archives/Public/public-webcrypto/2015Oct/0004.html

Cheers.

On Thu, Jun 2, 2016 at 10:37 AM, Hess, Bradley <Bradley_Hess@cable.comcast.com<mailto:Bradley_Hess@cable.comcast.com>> wrote:
We'd like for the committee to consider including a key agreement protocol and a key derivation function in the interoperability guidelines for implementers in Section 18.5.2.

Briefly, the interaction pattern that we hope to use extensively is:
 (1) Provision an in-browser client with a persistent asymmetric keypair appropriate for digital signatures.
 (2) During user sessions (e.g. video playback events), using the digital signature capability from step (1) as proof of client identity, negotiate an ephemeral shared key using a key agreement protocol.
 (3) Using the negotiated shared key from step (2), use a KDF to derive a key suitable for symmetric encryption.
 (4) Using the symmetric key from step (3), perform symmetric encryption and decryption.

We're satisfied with the recommended algorithms for asymmetric signing and symmetric encryption in the current draft, so steps (1) and (4) above are covered.  In principle we could get to step (4) from step (1) using the recommended asymmetric algorithms for encryption.  This has several disadvantages:
 - This protocol would be chattier due to the overhead of exchanging (and perhaps generating?) encryption keys.
 - The symmetric key would be passed over the wire.
 - It's not clear that we could control the exportability of the unwrapped symmetric key (I made a comment to this effect on GitHub issue #30; preventing export of KDF-derived keys depends on maintaining current behavior in issue #76).

Ultimately we think that the approach we've laid out is preferable for our use cases, so we're looking for help ensuring that client code that performs steps (2) and (3) will be portable across user agents.

Today we use DH and Concat KDF for key agreement and key derivation in deployed applications.  These have each been in the Web Crypto draft during its lifecycle though are no longer present.  While there would be less friction for us to continue to be able to use DH and Concat moving forward, we also respect that interoperability and adoption are best served by having a tighter baseline in the released Web Crypto spec, so we're open to other choices for the exact algorithms to use.  Ultimately we're more concerned simply that the baseline calls out both a key agreement protocol and a key derivation function that we can rely on in compliant implementations.


Cheers,

Brad

--
Bradley Hess
Principal Engineer, Content Security
Comcast Cable