Please consider key rotation, revocation, and distribution via a channel other than headers

[e271828-]

@mikewest thanks for taking this on, SRI really should have included signing at inception.

We currently use our own scheme for this internally, which involves publishing a pubkey via standardized DNSSEC records.

The file contents are then hashed and signed with that key, and the JS contains a header similar to:

/* { "version": "1", "id": "<key ID>", "hash": "<hash of file contents below header>" } */

Rotation and revocation is easy to manage through standardized DNS records.

DNS is a good channel from a security hygiene perspective when compared to HTTP headers: allows sites to reduce bandwidth, define their own policies around key lifetime and revocation speed, and let browsers cache these results efficiently.

One other point to consider: pinning to a single certificate or pre-set list of certificates is quite brittle and will require downstream updates to handle revocations.

Verifiers should be able to opt in to behaviors like "key X or any later version attested via DNSSEC secured record on package.my.com if X is revoked" at minimum.

Ideally you'd have a standardized intermediate / root certificate concept, so that trust is pinned to the root and intermediate certs can be used for signing and revoked without disruption.

[mikewest]

Thanks for the suggestion!

I think a scheme like the one you're suggesting is worth considering, but would require some work to specify in a reasonable way. That work might be worthwhile, but I'm starting with an approach that's aiming lower in the hopes of finding the simplest thing that could work so we can start gaining some experience with signing resources at scale.

I think it should be possible to layer alternative key discovery mechanisms on top of this kind of system without too much effort (by changing the type and keyid properties in some reasonable way), but shifting away from SRI's in-page pinning mechanism to one with the properties you're suggesting would require more thought. It shifts the trust model a bit, away from the provenance of a given resource, towards proving control of DNS. It's not clear to me immediately whether that's actually the same thing, or close enough that developers would want to use it in the same way (consider CDNs, for instance, where someone else controls both the frontend and the DNS; the scheme we're currently poking at ties the signature to the resource rather than the server, which seems appropriate for that use case).

I'll mark this as an enhancement. It seems worth discussing potential options, but I'll personally be prioritizing getting something simple out the door, and the current scheme is about as simple as I think we can make it. Based on deployment experience, we can decide together on the priority of building something with different distribution properties, and flesh out those proposals.

[e271828-]

@mikewest have you made progress on addressing these concerns?

I see this proposal is entering a Chrome origin trial, so will just repeat that we think it would be prudent to support a robust discovery option prior to finalizing the standard.

A large percentage of CDN users put their CDNs behind a host alias under a domain they control, so DNSSEC-secured TXT records are likely the best option.

Raising this now as we've gotten inquiries about this proposal, but cannot recommend it in its current form with no OOB key distribution or revocation mechanisms.

[mikewest]

Hi, @e271828-! No, I've done nothing with regard to these concerns. As I noted earlier, I'm aiming for the lowest bar possible to determine whether it's shippable. I'm certainly interested in feedback like this (that the bar I'm targeting is too low), so I appreciate the ping. Still, I currently consider any out-of-band distribution mechanism to be above and beyond what's necessary for a first pass.

As I noted above, it's not actually clear to me whether control of DNS is the same as control over a frontend server that can negotiate a TLS handshake. DNSSEC goes some distance towards equating the two, but they remain distinct (also in terms of distribution). It remains an important discussion, but I've made zero progress.

I'd appreciate your concrete suggestions about how you'd like to use this kind of functionality in the future. Can you spell out your idealized implementation?

[e271828-]

... I'm aiming for the lowest bar possible to determine whether it's shippable. I'm certainly interested in feedback like this (that the bar I'm targeting is too low), so I appreciate the ping. Still, I currently consider any out-of-band distribution mechanism to be above and beyond what's necessary for a first pass.

Not unreasonable, but when these things are deferred in the standards process it can sometimes take years before necessary updates are adopted.

As I noted above, it's not actually clear to me whether control of DNS is the same as control over a frontend server that can negotiate a TLS handshake. DNSSEC goes some distance towards equating the two, but they remain distinct (also in terms of distribution). It remains an important discussion, but I've made zero progress.

Control of DNS is already widely used to authenticate domain control, and is a higher bar than control of a frontend server. It can also be opt-in, as described below.

Can you spell out your idealized implementation?

Sure. Below is what we'd suggest.

Key version can be locked to pin-set:

<script src="https://amazing.example/widget.js"
        crossorigin="anonymous"
        integrity="ed25519-dnssec-{public key ID}-in-{version 1},{version 2}"></script>

or specify minimum key version:

<script src="https://amazing.example/widget.js"
        crossorigin="anonymous"
        integrity="ed25519-dnssec-{public key ID}-gte-{greater than or equal version}"></script>

DNS records:

{public key ID}.{version integer}._sri.amazing.example publishes a TXT record of base64-encoded pubkey.

{public key ID}.latest._sri.amazing.example publishes a TXT record of an integer, representing the latest key version available.

If we specify gte-1 and {public key ID}.1 is not found (i.e. revoked or rotated), we fetch {public key ID}.latest and then {public key ID}.{latest version}.

Asset preamble header, specified as first line:

/* ssri:{ "hash": "{base64 encoded hash digest}", "key_id": "{key ID}", "version": {version int} } */\n
... file contents to hash ...

This can alternatively be made very efficient and safe to parse directly, e.g. /* ssri:{hash}:{id}:{ver} */\n

Why do we prefer this design?

Security benefits:

• key revocation is cheap: either delete the DNS entry, or use a magic REVOKED value to avoid negative TTLs downstream
• OOB trust comes via DNSSEC, which should ideally be mandatory for this method
• simple versioning supports trust hierarchies, intermediates, and safe rotation
• simpler to serve, avoids many footgun scenarios as signatures can be e2e verified pre-deploy

Efficiency benefits:

• no HTTP header bloat per-request
• natively supports 'dumb' CDNs, no per-asset custom headers needed
• DNS TTL controls browser key cache; single call per host per TTL per (key id, ver) is generally enough
• hierarchical + regional caching via DNS comes for free
• checking AD flag on queries is very cheap if using DoH, otherwise client can opt to locally verify chain

[DemiMarie]

Clients should always be locally verifying the signature chain, unless user or machine configuration explicitly marks the DNS resolver as trusted. DNSSEC should be mandatory: without DNSSEC this whole mechanism isn’t supported.