On Mon, 25 Jul 2011 22:28:02 +0200, Gervase Markham <[email protected]>
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.
It might not be your first visit, just the first visit with that
particular client configuration
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.
My point is that the involved parties should start thinking about that
possibility now, rather than scrambling to manage a run-away success.
In such a situation the overload of the maintainers might easily cause
problems, perhaps leading to inflammatory messages about how "client X's
HSTS coverage is better than Client Y's" because one of them cannot handle
the update load, or isn't informed about as many sites as the other
client. That is the kind of scenario that I would like to avoid.
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.
It may be complicated, particularly given the need to sign with the
website key, but the intention was to be able to associate the signature
with the server(s) in question and confirm control of the server in a way
that might be less ambiguous than email.
This was meant as an initial suggestion. I'll let the WG discuss other
options if they want to take a look at the issues.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: [email protected]
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
