Resource integrity transparency

From: Eduardo Robles Elvira <edulix@agoravoting.com> · Date: Tue, 15 Jul 2014 15:31:28 +0200

Hello everyone,

Some weeks ago I suggested to do somethink called "isolated web
components". I was told that this might be done using iframes. In any
case, I proposed multiple security measures, and I believe that the
most important one was "pinning". I have thought a bit more about
that, and wanted to share these thoughts:

why not mix the idea of Certificate Transparency (CT) [2] and
Subresource Integrity (SRI) [0]? If a resource is supposed to have a
specific hash (like with SRI), then it should obviously not change,
and then we might well pin it and create a public log with it for
transparency. Web crawlers and interested parties could detect this
kind of resource pinning, and publish a cryptographically verifiable
log of pinned resources for transparency purposes, just like CT does
with certificates.

This would provide an additional barrier of security to CT: even if
the certificate for an FQDN has been compromised, if the pinned
resources change, it would be transparent and everyone could notice.
If SRI and CT make sense by themselves, I believe that those two
concepts together do make even more sense security-wise.

The way to mark a resource as pinned could be as simple as adding an
extra Header "Resource-Transparency-Pinning: True". One could also
provide another specific header with the expected content integrity
check, like "Resource-Transparency-Integrity:
ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript"
(extracted from an example in the SRI spec [0]). So if you want to
mark https://example.com/libs/jquery-1.4.1.js as pinned, just add the
appropiate header(s). A webpage could still use SRI to specify the
hash it expects, of course, and CT could also track the validity of
the TLS certificate. And HSTS. The more security measures the merrier.

The way to implement the verifiable crypto-log could perhaps be to
either reuse the techniques of CT, or maybe even open it to hash more
than certificates. This is something that should probably be discussed
in the IETF mailing list [1], but I believe that as this has to do
also with webappsec (in the same way as SRI does and it's discussed in
this list), I brought the topic first here.

What do you think about this idea? Is this the right mailing list to
talk about it?

Regards,
--
[0] https://w3c.github.io/webappsec/specs/subresourceintegrity/
[1] https://www.ietf.org/mailman/listinfo/trans
[2] http://datatracker.ietf.org/wg/trans/charter/