Re: Key Agreement and Key Derivation Guidelines

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