Hi Joe, Ok I'll bite:-)
I think I see what you're trying to do and agree its worth exploring. But I'm not convinced yet. Can you explain more about why you think that closing this particular gap is useful? For example, ISTM that a lot of bad URLs that are de-referenced are received in spam that won't contain this, or are in hrefs on pages loaded from sites that won't use this, or that attacks are trying to trick users into accepting a bogus version of a site that they have already visited (e.g. a bank). One way to answer this would be to show how this'd usefully mitigate some real current risk, but there may be other or better ways to answer too. (FWIW, I hope the answer ins't to the effect that UAs need to go through some gatekeeper site before going anywhere else, but I expect that'll not be your answer.) I'd also have some questions about how, e.g. re-directs etc but the above probably comes first. Cheers, S. PS: Your site has a mailing list/google group. Be great if an archive of that were visible, since maybe you've answered the above question already, but I don't have enough google-foo to know how to find that;-) On 02/13/2013 04:35 PM, Joseph Bonneau wrote: > Greetings all, > > I'd like to share a proposal with this list that I've been working on: > http://www.secure-links.org/ > > 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. > > Cheers, > > Joe > > > > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
