Re: WebRTC Certificate Management - a plea to NOT use Web Crypto

On Dec 23, 2014 11:31 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 23 December 2014 at 10:43, Ryan Sleevi <sleevi@google.com> wrote:
> > - Undoes three years of hard work to design some semblance of security
> > guarantees regarding what is usable and exposed.
> > - Introduces unnecessary ontological confusion by attempting to overlay
a
> > high-level semantic onto the notion of keys that the WG *repeatedly* has
> > rejected
> > - attempts to redefine the charter and scope of a WG and its key
deliverable
>
> Ryan, I'm seeing a lot of very strong language[1], but I'm having
> trouble understanding your objections.
>
> Let's see if I can try to ask some simple questions for clarity.
>
> If, as Richard proposes, you get a CryptoKey with a usage of 'webrtc',
> and that isn't good for anything but WebRTC, what risk does this pose
> to WebCrypto?  What security protections in particular does this
> ignore or jeopardize?

Martin,

At the risk of doing the thing I so hate, I encourage you to reread the
past message. This line of questioning is itself unproductive - you're
starting from the point that "this is the right way, prove it wrong" - and
is not at all fruitful to coming up with alternatives. That's why I very
carefully tried to start from "This is what you say you need, what is
proposed won't get you get you there, here's alternatives".

Let's look at the meat of the proposal:

https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#cryptokey-interface

- Does WebRTC need usages? No. It is only and always webrtc.
- Does WebRTC need type? No. Private keys are never usable by the proposed
browser-lock API.
- Does WebRTC need extractable? No. It is always browser locked.
- Does WebRTC need algorithm? No. It is clear that what is specced is not
appropriate, and what is appropriate is intentionally not specced.

So from Key alone, it is clear that zero is applicable to WebRTC via IDL.

Now let's look at methods:
- Can WebRTC get a key via importKey? No, keys have to be browser locked.
- Can WebRTC get a key via unwrapKey? No, keys have to be browser locked.
If the unwrapping key was extractable, then it violates browser locking.
- Can WebRTC get a key via deriveKey? No, keys have to be browser locked.
If the derivation key is extractable and the derivation scheme determistic,
then it violates browser locking. Similarly, if deriveBits is supported, it
violates browser locking.
- Can I generate a key via generateKey? ONLY if I supply parameters that
are different than how I generate the "equivalent" Web Crypto key, and ONLY
if I use the RTCIdentities IDL.

What about when I have a key?
- Can I use sign/verify/encrypt/decrypt/wrap/derive*? No
- Can I use exportKey? ONLY if the key is a public key. It requires you to
specify a format, which for public keys is PURELY syntactic sugar.

So let's recap, and spell it out explicitly:
- Every attribute on CryptoKey is irrelevant for WebRTCs use and merely
serves either as redundant or conflicting data for script authors.
- The only Web Crypto API method it can be used for is exportKey.

That is a horrible experience for developers. The PR spends more time
carving out how WebCrypto keys can't be used than it does on why they're
even reasonably fit for purpose.

That alone is reason to soundly reject this proposal.

But since you presented it as "What harm does it do to WebCrypto" - rather
than focusing on the harm it does to the platform, through ill-fitting
abstractions - simply look at what is being proposed to developers.

The proposal, to make any sense, requires one of two things:
- That WebRTC explicitly ignore what is a designed security feature and
property of Web Crypto; namely, strongly binding keys to algorithms.
- That script authors be taught that it is OK to omit necessary security
parameters, such as hash, but only sometimes and depending.

The former is to encourage, both here and as Richard notes, push messaging,
that it is OK for external specs to actively ignore the security
considerations of specs when aping bits of IDL from them. The latter is to
create an inconsistent experience for developers where the thing they're
told is an apple needs to be called an orange some of the time, and apple
the rest of the time.

Introducing a means to generate Web Crypto keys outside of the Web Crypto
API should be rightly realized as downright dangerous. Despite Richard's
claims to the contrary, the CryptoKey used in window.crypto.subtle was not
designed to be the generic representation of keying material in the
browser, precisely because such generic representations are inherently
inappropriate. It was not oversight that lead to this, not a spec defect,
but intentionality in charter and execution.

If we wanted such a generic representation, it would have been simply a
naked type - the API equivalent of a void-pointer - and unused in any
actual IDL precisely because every single use of keying material needs
context for the operation it is, and that context does NOT traverse specs.

Any evaluation of the security properties of Web Crypto can no longer be
completed in isolation; reviewers need to know about the (unregistered)
usage of 'webrtc' and carefully examine what the implications are. The PR
fails to even approach treating these complexities, ones which I spelled
out months ago. Consider adding 'webrtc' to the usages - now all places in
Web Crypto that treat usages relevant to Web Crypto must know to
special-case and exclude it. Does JWK's key_ops get updated? Yes or no, it
adds further complexity; either it has to be spelled out that no one should
ever use it (lest they introduce a vector of importing non-locked keys,
upon which your security proofs rely) or it has to spell out in all the
places that shouldn't have to care that it has to filter the 'webrtc' keyop
out.

Rather than trying to make the existing PR fit, something I think would be
deeply mistaken given how little of the requirements have been documented,
I think the productive path forward would be to set forth the requirements
and use cases. Then, proposals such as this can be examined on their
merits, such as:
- How natural is this fit with the Web Platform?
- What is the developer experience?
- What changes are needed to accomplish this?
- How and why might we extend this in the future?
- What are the security implications, both explicit (literal) and implicit
(in the patterns we encourage of devs)?

My hope is that, in doing so, you all reach the same conclusion I have -
that the proposal in both letter and spirit is an ill-fit with significant
implications to both APIs.

>
> --Martin
>
> [1] Frankly, I'm shocked that you think this tone is acceptable.

I'm shocked this proposal was brought to the group. The ontological
construct of Keys being a metatype was rejected previously, the overloading
is acknowledged within the PR as being an ill-fit and problematic for the
Web Crypto WG, it effectively monkey patches the spec, and efforts by the
authors within the WG to bring a high-level API in were routinely pointed
out as out of charter.

This design was raised privately, wherein I expressed a number of serious
misgivings about the appropriateness, suggested alternatives and raised
objections. To see this same proposal -  without any attempt to resolve
these concerns or even a presentation or acknowledgement of how many there
- are is profoundly frustrating and suggests that all efforts previously to
avoid this and improve it were considerable time well wasted. The only
conclusion readily apparent, outside of bad faith, would be that it wasn't
realized how serious these concerns were, and making sure it is abundantly
apparent that this is an ill-fit through unambiguous and unhedged language
hopefully expresses this. You can see the tone as strong, whereas my goal
is no misrepresentation to ambiguity in my position.