New proposal: S-links (secure links)
Joseph Bonneau <jbonneau <at> gmail.com>
2013-02-13 16:35:35 GMT
My goal is to enable a lightweight, incrementally deployable way to distribute security policies for servers users have never visited. I think that links in HTML are a natural place to do this, because the act of clicking a link is a de facto statement that the user trusts the enclosing to send them to a new destination.
S-links can be part of an "end-to-end" key pinning solution as follows:
(a) Browsers ship with some hard-coded key pins for the the largest sites on the web. This pins connections to popular "hub" sites like search engines, social networks, link shorteners, etc.
(b) These sites can observe sites asserting key pins around the web (ie through HPKP records, DANE, or other mechanisms) and serve s-links to such sites. Users find the majority of new sites to visit through these hubs, and their initial connections to them are secured through s-links.
(c) After the (s-link protected) initial connection to a new site, browsers can negotiate persistent key pins through HPKP or another continuity-based protocol.
Without something like s-links, preloaded pins can't scale to the web, and continuity-based protocols suffer from a vulnerable initial connection. I think that building a mechanism to deliver pins "in-band" through web linking can close the gap in the common case.
I'd also like to point out that this is a flexible mechanism with a similar end-to-end story for other protocols (I mentioned other possible directives besides key pins). For example, to achieve incremental deployment for Certificate Transparency (ie, start hard-failing before every CA has opted in) we could start with browsers pre-loading a list of "CT mandatory" sites. If these sites are major web hubs, they can use s-links to indicate other "CT mandatory" sites. If we then bolted on a "CT mandatory" bit into a continuity-based protocol, many sites could get CT protection before CT is universally deployed.
I'd very much like feedback on the proposal and how it can fit in with others. There are a number of tricky issues here with the browser's same-origin policy that I've gotten some feedback from the Chromium project on, and I've tried to keep an extensive FAQ on the web page with issues that have come up.
therightkey mailing list
therightkey <at> ietf.org