On Mon, 2011-07-25 at 20:13 +0200, Yngve N. Pettersen wrote: > At least one client supporting HSTS (maybe more) is using a hardcoded list > of sites that are always HSTS enabled, as a method of countering the > bootstrap problem. > > As I understand it, the process for how a website get on such lists is > currently very ad hoc, which isn't really a problem at this time, since it > is experimental. > > However, once HSTS moves into standardized deployment, it may be that many > websites will want to get listed on such a list
The obvious solution is to put the data in DNSSEC. The problem is that current deployments are hostile enough to DNSSEC to make fail-secure a painful experience. I'm seeing this now using nss-dane ( https://mattmccutchen.net/cryptid/#nss-dane ) for my personal browsing: so far I've poked seven exceptions for broken DNS servers, and on some public access points I cannot get through to DNSSEC at all. If anyone has an idea to make this better, let me know! Ditto the above for the public suffix list. It's currently the only way to really isolate untrusted subdomains so you don't have to make all your applications robust to cross-subdomain cookie forcing. -- Matt _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
