Proposal: not-a-scheme digest URI scheme, with graceful degradation

Hello everyone:

I'd like to first bring to your attention the benefits of a digest uri
scheme. There have been proposals in that direction at IETF [0]. It's
related to SRI (Subresource Integrity) and tries to achieve something
similar but at a different level; the fundamental idea is that the
integrity of a resource is checked based on information provided by
the URI.

I find reasonable to question why why SRI is advancing and a digest
uri scheme isn't [4], in the world of web-browsers. I guess that a
possible answer is the following:
1. older browsers don't support new URI schemes, so it's not just
something optional as SRI is. there's no easy graceful degradation
here
2. URIs are something that users see, so it's something much more
visible and traumatic for users

Those arguments seem already quite good. But what if.. we could solve
at least the first issue? Then I believe that it might be worth to
ponder the idea.

The proposal I'm going to make is very simple and a bit hacky. To
generate the equivalent to a digest URI, an user uses a specifically
crafted standard http/https url, that refers to a previously agreed
domain. The web-page of this domain will generate a redirect to the
real URL, using SRI.

Note that in the current SRI draft, only downloadable anchors can have
integrity verification, as we have discussed in this mailing list
before. This implies that this not-a-digest-uri-scheme proposal might
only be available for downloadable links [5]. That reduces the
possible usage of these links, and I might try to challenge that idea
later, but even accepting that, this not-a-scheme URI scheme could
still be as usable as SRI for downloadable anchor links.

Let me ellaborate a bit on the proposal. First, let's assume that the
"security-proxy domain" used is securelink.com for example [1]. Let's
explain how this would work in three different use-cases. All of them
start with this:

An user receives by some secure means a link like the following one:

https://securelink.com/sha256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc/https://agoravoting.com/download/agoravoting-3.0.tar.bz2

The user opens this url in the web browser somehow (using the address
bar, clicking on a link, launched in the browser by a third
application..). What would happen?

--

## Case A: A web browser supporting the new not-a-scheme digest URI scheme

As this is a supporting web browser, the web browser notes that this
link uses the securelink.com domain, and launches the pinned
html/css/js code that basically creates a downloadable
integrity-checking anchor link and clicks on it. This pinned code of
securelink.com ships with the web browser, and the link's downloadable
content is checked for integrity. Thus the link is deemed as "secure".

## Case B: A web browser NOT supporting the new not-a-scheme digest
URI scheme BUT supporting SRI

This web browser does not know anything about the securelink.com
domain, so it acts as with any other domain. Launches the domain,
which contains some html/css/js that basically creates a downloadable
integrity-checking anchor link and clics and opens it, checking its
integrity first.

In this case, the link is as secure as in the previous example, unless
the securelink.com has been compromised.

## Case C: A web browser NOT supporting the new not-a-scheme digest
URI scheme and NOT supporting SRI

This web browser does not know anything about the securelink.com
domain, so it acts as with any other domain. Launches the domain, with
contains some html/css/js that basically creates a downloadable
integrity-checking anchor link and clics on it and opens it, ignoring
the integrity metadata because it doesn't understand it.

In this case, the link has similar security as any normal link, i.e.
it's secure in unless securelink.com or agoravoting.com have been
compromised.

--

As you can see, this not-a-scheme digest URI scheme has graceful
degradation. And that is interesting. Also note that even if the
scheme proposal is not implemented in a web browser, it could be
implemented as a browser add-on (and still would be case A), and even
if that does not happen, this could be still useful as in (Case B), to
centralize this kind of link-security in one domain.

I know this seems like a hack, but it solves real problems, provides
extra security, and it does so with mechanisms not that far away from
the things that are already doing browser vendors. For example, some
web browsers ship with pinned certificates for some domains (i.e.
google domains in Google Chrome), and there are some standard reserved
top level domains like example.com [2] [3].

There can be multiple ways to proceed regarding the "security-proxy
domain". We could just buy a domain for many years, and use it as
explained. Or the same could be done with a complete TLD address
space. Or RFC 2606 [2] could be modified to add this feature, but I
guess that wouldn't happen as that RFC is general to Internet and not
specific to web browsers.

Anyhow, what do you think about this crazy idea? Hopefully I'm sending
it to the correct mailing list, and in any case, i hope you find it
interesting and take it into consideration. And if this is not the
correct mailing list, please accept my apologies, and I'll end it
somewhere else if you point me in the right direction.

Regards,
--
[0] http://tools.ietf.org/html/draft-hallambaker-digesturi-02
[1] just an example, this domain is already in use
[2] http://tools.ietf.org/html/rfc2606
[3] http://example.com/
[4] Don't get me wrong, I'm not against SRI, and I like the idea and
will actually use in this proposal, and I think both should co-exist
[5] That's not actually true: there could be an exemption in the
implementation if need be, read below
-- 
Eduardo Robles Elvira     @edulix             skype: edulix2
http://agoravoting.org       @agoravoting     +34 634 571 634

Received on Saturday, 20 September 2014 12:08:37 UTC