Re: Key Agreement and Key Derivation Guidelines

Oh I see, apologies for misunderstanding then!

Yes that sounds reasonable -- adding HKDF and ECDH to that list.

This assumes that we keep section "18.5.2. For Implementers" in the spec,
and that the implementations meet the bar for interoperability that is
being codified with the conformance test suite currently under development.

I agree that having broad support for HKDF and ECDH such that web
developers can rely on it would be super.

I believe your request is already addressed by
https://github.com/w3c/webcrypto/issues/12 -- but feel free to drop a
comment in there.

There has been a lot of discussion around the issue of minimum/expected
algorithm support and how to convey it (if at all) in the spec, which I
won't rehash here. But it is safe to assume that Section 18.5.2 is going to
need edits one way or another.

Cheers.

On Thu, Jun 2, 2016 at 1:50 PM, Hess, Bradley <
Bradley_Hess@cable.comcast.com> wrote:

> Sorry; I should have specified: by "those algorithms" I mean HKDF and
> ECDH.
>
> On Jun 2, 2016, at 4:46 PM, Hess, Bradley <Bradley_Hess@cable.comcast.com>
> wrote:
>
> 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> 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> 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
>>
>>
>>
>
>
>