Hi,
As mentioned just now in the Websec WG meeting.
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, which created a few
scalability problems:
- Number of clients maintaining such lists
- Number of sites that want to get on such lists.
While HSTS is not going have the same problem severity, a similar problem
exists in a more limited fashion, in the deployment of Root Certificates,
where it causes some interoperability problems when sites use a Root
Certificate not deployed in all clients (properly deployed HSTS will not
run into those, but might encounter downgrade attacks).
For HSTS I expect that the number of websites wanting to get on the
list(s) is going to number in the thousands (with one million sites, even
0.1% is 1000), which is likely to cause trouble for the maintainers of the
list(s). However, the website administrators might also run into trouble
locating all the lists they want to be on, and notifying them about their
intention.
The first question the websec group need to answer is whether or not it
should define how such a hardcoded list should work?
If the answer is yes, how should it be maintained? Should it be a single
central repository? Who should host it and accept applications?
My thought is that there should at most be only a few such repositories,
and that the process of getting listed should be as automatic as possible,
while avoiding fraudulently added entries.
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,
chained to a list of approved CAs (which opens up another problem area of
selecting those CAs). When approved the list is updated with the new
entries, and then distributed to the relying parties. Using a digitally
signed submission will make it harder to submit a fraudulent application,
preventing a denial of service attack.
--
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
