Subject: [websec] HSTS: Maintenance of hardcoded lists in clients

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 25 Jul 2011 20:13:38 +0200

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-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Adam Langley <[email-masked]>
Date: Mon, 25 Jul 2011 14:20:22 -0400

On Mon, Jul 25, 2011 at 2:13 PM, Yngve N. Pettersen <[email-masked]> wrote:
> 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).

I maintain one of these lists (for Chrome) and it is, as far as I
know, the only one. I haven't had a request for addition in nearly two
months.

If, as I hope, this becomes a flood in the future, I'm sure that we
can figure out a solution. We quite happily manage
http://publicsuffix.org/ in common, for example. But, for now, it's
such a non-problem that I don't believe that it's worth bothering
about.

Cheers

AGL

---

From: Gervase Markham <[email-masked]>
Date: Mon, 25 Jul 2011 13:28:02 -0700

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.

> central repository? Who should host it and accept applications?

As Adam says, I'm sure we can come to a publicsuffix.org-like arrangement.

> 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.

Gerv

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Jul 2011 23:54:17 +0300

> 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.

> As Adam says, I'm sure we can come to a publicsuffix.org-like arrangement.

Agree.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 25 Jul 2011 22:59:37 +0200

> 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

> As Adam says, I'm sure we can come to a publicsuffix.org-like  

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.

> 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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 27 Jul 2011 01:29:29 +0200

>clear their history, but I suspect that's a relatively rare action.

Actually, that's usually the first thing you are told to do when your
browser doesn't work quite right with a site and there aren't many de-
tails to go on; often the web sites will tell you to clear the cache,
http://www.google.com/support/accounts/bin/answer.py?answer=32050 for
instance even has videos on how to do it. Users might not do this ha-
bitually, but a man-in-the-middle would seem to have plenty of ways
to try and persuade users to do it (he could book an ad suggesting to
do this to users within the geographical region, for instance).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Jul 2011 20:24:56 -0400

On Mon, 2011-07-25 at 13:28 -0700, Gervase Markham wrote:
> that site, so the risk is much lower.

No... in the general case, you are dereferencing a https URL provided by
someone else who expects you to use server authentication.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=653318#c3 that I just
posted; it refers to the risks of not using server authentication at
all, but the risks of not knowing about HSTS are analogous.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Jul 2011 20:37:02 -0400

On Mon, 2011-07-25 at 20:13 +0200, Yngve N. Pettersen wrote:
> 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

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Jul 2011 20:50:25 -0400

On Tue, 2011-07-26 at 20:37 -0400, Matt McCutchen wrote:
> I'm seeing this now using nss-dane
> browsing: so far I've poked seven exceptions for broken DNS servers,

I should clarify: these seven are all insecure zones, so if I made the
client check whether the zone is verified-insecure rather than just
stopping on the query failure, I would be OK.  The phenomenon of
ostensibly "high-performance" or "locked-down" DNS servers that don't
support enough of the protocol to prove the non-use of opt-in schemes
has not appeared yet for secure zones.  Let's hope it never does.

> and
> on some public access points I cannot get through to DNSSEC at all.

But this problem isn't going away any time soon.

-- 
Matt