Re: [w3ctag/design-reviews] Review of signature-based resource loading restrictions. (#186)

Hey, @plinss! Thanks again for the feedback!

Let me first point again to https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html, which aims to offer the ability to sign things with certificates. That has real use cases, and it's something y'all should give feedback on (especially given Mozilla's apparent disapproval). That mechanism could indeed serve as the basis for a client-side assertion that a resource was signed in such a way that it chains back up to some trusted root, and if it takes off, I could certainly imagine adding some sort of client-side assertion regarding its presence. There are some real complexities there with asserting a particular public key given the weirdness that is path-building and cross-signing and etc, but I'm sure we could work something out.

That said, I have a few thoughts about the threat you're concerned with preventing:

1.  It seems non-unique to this mechanism. That is, the bad actor can put up a malicious copy of jQuery today, along with a hash that would verify that malicious copy: developers who trust the bad actor could certainly be tricked into asking the browser to intensely verify that they're loading the bad actor's code, which would indeed end up executing the bad actor's code on their pages.

    It doesn't appear to me that moving from a hash to a signature makes the problem any worse. In fact, I'd claim the opposite, as the bad actor would have significantly more opportunity to feed a bad hash to a developer since the hash by definition must change every time the resource changes. It seems that signatures might be longer-lived, and therefore less-frequently updated, reducing the opportunity for maliciousness.

2.  The use cases I know about are not actually related to third-party content at all. There might be some marginal value there, but my focus is on first-party content (or third-party content that's audited and part of a deployment process that stamps it with the first-party key). I'm not actually enthusiastic about the third-party use cases (some of the reasons for which are outlined in the discussion with @sleevi in the thread I linked back at the beginning of this review).

> My concern is that the end user has to know the public key of the resource signer via some
> form of out of band communication.

That's true of certs as well, isn't it? The root certs for the web PKI are distributed either with your OS or your browser, and are trusted accordingly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/186#issuecomment-362250593