On Jul 25, 2011, at 4:28 PM, Gervase Markham wrote: > On 25/07/11 11:13, 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. > > Is "the bootstrap problem", the problem that on your very first visit to > a site, you might get MITMed? > > If it's your very first visit, then you won't have a relationship with > that site, so the risk is much lower. I guess there's also people who > clear their history, but I suspect that's a relatively rare action.
Clearing history is rare, though not unheard of. But using a website for the first time from a particular device is not that rare. People get new computers and new phones occasionally. They also change browsers and re-install operating systems. > >> If the answer is yes, how should it be maintained? Should it be a single >> central repository? Who should host it and accept applications? > > As Adam says, I'm sure we can come to a publicsuffix.org-like arrangement. Agree. > >> A strawman for such a automatic system could be that the website >> administrator submits a list of servers/domains that are to be HSTS >> enabled, digitally signed using (one of) the website's own certificate, > <snip> > > This seems overly-complicated. I'd accept a email-challenge-response > verified request from an email at that domain, coupled with an automated > check that the site(s) in question have in fact deployed HSTS.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
