Re: Proposal: Signatures in SRI.

On Thu, Jun 1, 2017 at 6:18 AM, Mike West <mkwst@google.com> wrote:

> On Thu, Jun 1, 2017 at 11:42 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> I think that signatures solve some of the concerns I've been seeing
>> with SRI deployment, the biggest one being that you need to know what
>> the content is before you can link to it.  This would add a layer of
>> indirection, allowing you to identify a signer.
>>
>
> Right. I think it has real deployment advantages, especially for
> first-party resources (your own code), and quasi-first-party resources
> (colleagues with whom you have direct integration points).
>
> sleevi@ and agl@ note that the usefulness for truly third-party resources
> is limited, because key management is hard. It would be nice to ensure that
> `https://apis.google.com/js/platform.js`
> <https://apis.google.com/js/platform.js> is signed by Google, for
> instance, but hard-coding a public key into a million websites that embed
> that resource would make key rotation prohibitive, leading to some risk of
> key pinning suicide, similar to the risks that appear with HPKP.
>

Right. I think articulating the deployment scenarios - both with SRI-Hash
and SRI-Sig - is extremely important in determining whether or not this
provides value relative to the risk of the ecosystem.

Perhaps incomplete, but my proposed set of categories to consider are:

"Full" 1P - A single organization with a monolithic view of its code and
dependencies. At any given time, a given page knows all of the expected
versions/contents of its related dependencies. Publication is always
centrally coordinated.
"Quasi" 1P - An organization that might have multiple independent teams and
versioning strategies, and not enforcing them via URLs. e.g. an
organization that has Team X working on Component A, and Team Y working on
Component B, and Team Z working on the overall Site, which ingests
(unversioned) Components A and B. In this case, publication is not
centrally coordinated (Components A, B, and the Site may all update at
independent cadences), but they're all part of the same logical
organization.
"Versioned" 3P - A site is ingesting resources from one or more
third-parties, at explicit versions
"Rolling" 3P - A site is ingesting resources from one or more
third-parties, each of which independently updates on their own cadence
(providing backwards compatibility to the site, to some extent)

I propose these categories because it affects the deployment discussions:
- Full 1P can use SRI-Hash, because there's a central publication mechanism
in which all of the SRI hashes can be computed/known, and thus injected as
appropriate.
- Quasi 1P can't use SRI-Hash, because Components A and B are independently
updating at a cadence distinct from Site. They believe they can use
SRI-Sig, because as a singular organization, they can coordinate signing
activities as part of the publication stream. In the event of a key
rotation, all resources must be republished (with the new/rollover key),
but continuity is otherwise maintained
- Versioned 3P can use SRI-Hash, because the dependency graph of 3P
resources is known at time of 1P publication.
- Rolling 3P can't use SRI-Hash, because the constant update of 3P
resources would otherwise mean an endless update of 1P hashes. Rolling 3P
thinks it can use SRI-Sig, because then it could just express the keys of
the 3P publisher. However, a 3P experiencing a key rollover event would
require all consuming 1P to republish with the new key.


So the use cases that shake out are Quasi 1P (but with centralized
publication for key rotation) and Rolling 3P. However, I think both of
these cases are wrong and bad for security and the ecosystem :)

Quasi 1P still has to maintain a centralized republication mechanism (e.g.
what Full 1P has) in order to handle key rollover events. A Quasi 1P entity
that doesn't is just setting themselves up for breakage in the event of a
key rollover event, the inability to publish (in the event of a key loss),
or the loss of security (in the event of a key compromise). Two of these
breakages directly affect users (the greatest constituent) for reasons
beyond their or the UAs control - that is, it's a footgun. The third
undermines the security guarantees, and thus isn't particularly compelling
for the UA.

For Quasi 1P, I would assert that having the 1P have the capability to do
centralized publication is a net-good for their deployment, and the
experience of users. And while I realize that's telling site operators what
to do, it's also recognizing that SRI-Sig is not going to solve their
problem.

Rolling 3P is just building an ecosystem ripe for massive user disruption
and the eventual disabling of SRI-Sig because of that. If you imagine a
situation like some ad or analytics vendor publishing their key for
consuming 1P, then any time they update that key (rotation, loss,
compromise), all of those 1P become broken, which means the user experience
is broken, which means the user agent is, while properly observing the site
authors intent, breaking the Web for users. It too is a giant footgun.

Once you introduce SRI-Sig, however, it introduces a desire to get 'clever'
with signatures, as is always the case. The argument for a design that
avoids these issues is something like the 3P has a 'long-term' high
security key (that all of 1P consume/encode in their page), and that signs
a 3P resource that then 'chains' to the 'short-term' key used to sign the
rolling updates. This is the classic offline/online PKI scheme - reflected
in a variety of systems, most notably, the Web PKI. Once you introduce this
chaining scheme though, you introduce worse user experience (since it's
SRI, each of these signatures is effectively achieved by loading a
subsequent resource - meaning you've got loading order pain), and you
introduce a need for things like Key TTLs or Revocation (since without
them, your online key isn't reducing the threat surface, since you can
always do version rollbacks to a compromised key). And since it's something
that 'anyone' could deploy, it makes it more likely that just like 10 year
TLS server certificates (that people forget about / how to replace), these
'offline' keys are at an even greater likelihood of going missing.

To me, it seems like SRI-Sig's "use case" is to support SRI for the case of
'rolling updates', without requiring awareness of what those updated
resources are. This does match the deployment reality of the Web - that 1P
entities are often in the "Quasi 1P" scenario without centralized
coordination/publishing (and I believe that is Mike's intended use case),
and that most of the 3P resources - things like analytics and ads - are
equally on 'rolling updates' without centralized coordination.

I can understand the desire and appeal to want to provide better assurance
for these deployments. I just don't think this meaningfully does so, in a
way that doesn't introduce giant footguns to the Web compatibility story. I
think the level of support for SRI-Sig depends on how much you believe the
Quasi-1P and Rolling-3P scenarios are 'valid' and 'good' to begin with, and
how much you believe SRI "should" apply to them. I don't believe they're
good (but they're real and the majority), but more importantly, I think
that if you want to adopt those models, then the security tradeoff is
unavoidable, because the usability tradeoff is too high.