Key Agreement and Key Derivation Guidelines

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

Received on Thursday, 2 June 2016 19:15:34 UTC