Hiya, On 02/14/2013 05:47 PM, Joseph Bonneau wrote: >> Fair enough, but my question is: what does this deal with? Can you >> give a walk-through of a bad thing that does happen, and how that >> bad thing is less likely to happen or be exploitable if this >> mechanism is deployed? Honestly, I'm not seeing it. > > > Sure, the parable would be this: Brian wants to visit the Judaean People's > Front website but his local ISP is run by the Romans, who also control the > RomeTrust CA. The JPF website is wisely using HPKP to pin clients to their > correct key. However, they're too small of an organization for the browser > to pre-load this. Brian does have a genuine browser, which has key pins for > the connection to his search engine which is outside of Roman control. > Without S-links, Brian has no easy way to navigate to the JPF website and > confirm that there isn't a centurion-in-the-middle attack which blocks the > HPKP pins from ever being delivered. With s-links, his search engine can > include the JPF's key pins (which they observed when crawling and indexing > the site), allowing Brian to get there safely. He can then access that > website directly (through history, bookmarks, recently-closed tabs, etc.), > without needing the search engine anymore, as the HPKP pins will protect > future connections.
Ok, so that needs Brian's browser to know about all possible search engines Brian might use, that all of those scrape the JPF site (and not the Roman fake:-) for keys and that Brian does go to the JPF site for the first time by clicking on a search result. If the centurions don't specifically care who they MITM then spam works for them, if they do care, the spear-phising will likely work anyway since Brian's a bit naive. In terms of detecting that MITM attacks are being attempted, I guess this gives much less of a signal than HPKP and/or CT as its only producing a different signal for that 1st time ever. (I don't think that the centurions can avoid being spotted by already pinned JPF clients in general but still attempt MITM against 1st time connectors can they? If they could we should consider that as a flaw in HPKP maybe.) That just seems like a lot of pre-arranged stuff being required and overhead for all search engines when Brian is as likely as not to go straight to the site, or be tricked into doing so by the centurions. > Similar story for CT... > > >> For webmail and social networks there's an account setup phase >> where I'm not sure this helps and after that HPKP or whatever can >> kick in. Link shorteners maybe, but I'm not sure what's proposed >> for that (the hash of who's key is where and checked when?). And >> for search engines, I don't see how my browser will know that >> duckduckgo use this and do that well enough to block something >> without creating a possible DoS from any bit of HTML that >> convinces my browser to believe in the link-security attribute. > > There's no DoS possibility because s-links have no persistent effects. All > a "malicious" s-link can do is cause a broken link. Broken links already > exist, this is not exciting. You might be right, I guess it depends on how browsers decide when to believe link-security or not. If they only believe the pin when its presented via a live TLS server authenticated connection from an already pinned search engine that might be ok, but then wouldn't that make any cut'n'pasted links liable to barf? (When Brian sends the link he got to the JPF site via email to Reg, then if the PIN is ignored then the centurions could get Reg, but if its not ignored then Brian or anyone maybe can DoS Reg.) >> Well, today's reality is not what was reality a decade ago. And I >> firmly believe we're likely to see as much or more change in the next >> decade, so I'm uncomfortable with solutions that depend on today's >> top-10 sites or anything similar to be honest. >> > > Browsers now update at least monthly (and this update itself is pinned and > assumed secure). That is a change that's positive when arguing for mechanisms like this I agree. > So it's easy to change the list of pre-loaded sites. If > the structure of the web graph changes dramatically and there isn't a small > central hub of introducer websites, then this solution would change. But > this structure hasn't changed much, the web has only become more > concentrated. Nonetheless, mechanisms like this aren't ideal esp. if they don't quite work well enough security-wise, but do clearly further increase all of our dependencies on fewer and fewer point of real control. But again, I'm more interested in the former aspect now (whether this has enough security pay-off). > Hope that helps explain my motivation? Sure, I got the motivation all along. Its whether or not the mechanism is useful enough that puzzles me. I'm still not convinced, but would be interested in seeing it further worked out. Cheers, S. > > 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
