Subject: Re: [websec] Notes from an HSTS Meetup (Sep. 2016)

From: Eric Mill <[email-masked]>
Date: Fri, 20 Jan 2017 13:38:26 -0500

As a follow-up to the part of the notes about .gov, and potentially using
the HSTS preload list as a migration pathway -- that's what the .gov domain
program (an office of GSA) announced yesterday:

https://cio.gov/automatic-https-enforcement-new-
executive-branch-gov-domains/

We're using the preload list to start closing the door on plain HTTP in
.gov, for executive branch agencies to start, in a way that we feel
confident enough won't break anything.

The relevant excerpt:

This year, GSA will be taking another significant step forward in making
secure communication the default for federal web services by *automatically
enforcing HTTPS* in modern web browsers for *newly issued executive branch
.gov domains* and their subdomains.

As new executive branch domains are registered, the dotgov.gov program will
submit them to web browsers for “preloading”. After submission, it can take
up to three months before preloading takes effect in modern web browsers.
The change will be introduced to dotgov customers when they register a new
domain under the Executive Branch, and *will not affect existing or renewed
domains*.

Once preloading is in effect, browsers will strictly enforce HTTPS for
these domains and their subdomains. Users will not be able to click through
certificate warnings. Any web services on these domains will need to be
accessible over HTTPS in order to be used by modern web browsers.

We'll be finalizing the mechanics of how .gov programmatically sends
entries to the preload list with Lucas and his team over the next month.

It's a novel approach, and potentially could serve as a model for other
TLDs or suffixes -- so if folks have any feedback or suggestions about this
effort, it'd be welcome and timely.

-- Eric

On Thu, Jan 19, 2017 at 8:03 PM, Lucas Garron <[email-masked]> wrote:

> Hi all,
>
> Last September I organized HSTS meetup, and I'd like to share public notes
> of what we discussed: bit.ly/hsts-meetup-notes
> <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#>
>
> Most major browsers had at least one participant, and since I currently
> maintain the Chromium HSTS preload list <https://hstspreload.org/>, I set
> roughly half the agenda to discuss the HSTS preload list.
>
> Some highlights:
>
>    - We collectively documented the HSTS preload list processes
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#heading=h.gpm9zj53wbk5>
>    for Mozilla, Microsoft, Chrome, Opera, and Safari in one place for the
>    first time. I also also made slides documenting the Chromium preload
>    list submission process.
>    <https://docs.google.com/presentation/d/1TdSPLBqkeSGZ3mFO6bSpHaRKKwPVDzU_xVc7q5vdHrY/edit#slide=id.p>
>    - The HSTS preload list has roughly two major issues: stale/removed
>    entries, and potentially very large growth in the near future. To help
>    address this, most browsers could support out-of-band updates
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#bookmark=id.5gjn9r3a8p80>
>     if it becomes necessary. (In fact, it seems Firefox just implemented
>    this <https://twitter.com/rlbarnes/status/819640097972822020>.)
>    - Firefox has implemented HSTS priming
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#heading=h.vpdezmng8pxs>,
>    which addresses the fact that HSTS on its own does not prevent mixed
>    content. Chrome is interested in implementing this, too. :-)
>    - Related topics: history of HSTS, HSTS history leaks and
>    supercookies, how to handle demand for content filtering when HTTPS is
>    common, how to get to a place where the web can be HTTPS by default, how to
>    switch entire TLDs to HTTPS, how to prevent developers from accidentally
>    preloading.
>
> (One planned topic that we didn't end up discussing much at the meetup was
> standardizing the `preload` directive used by hstspreload.org)
>
> Based on the discussions, I am also planning to make several changes to
> https://hstspreload.org in the near future:
>
>    - Automatically handle removal requests and prune stale entries
>    <https://bugs.chromium.org/p/chromium/issues/detail?id=608599> using daily
>    scans <https://github.com/chromium/hstspreload.org/issues/35>.
>    - Once we're confident about pruning process keeps the list
>    up-to-date, get all browsers to draw from the same source of truth
>    <https://github.com/chromium/hstspreload.org/issues/76> instead of
>    filtering each other's lists. (This can reduce delays for new/removed
>    entries by several months.)
>    - Possibly raise the submission requirements
>    <https://hstspreload.org/#submission-requirements> to a minimum
>    max-age of 1 year
>    <https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrXNBIbI/edit#bookmark=id.s9cg5xbp1r1m>
>    .
>
> martijnc@ has also been contributing changes
> <https://bugs.chromium.org/p/chromium/issues/detail?id=595493> to
> Chromium that will make my life as maintainer easier. :-)
>
> Apologies for the delay if anyone was waiting on this. I had a lot of
> non-HSTS work to do last quarter, but I've started work on hstspreload.org
> for the bullet points above, and plan to dedicate a significant amount to
> this in early 2017.
>
> Many thanks for all the meetup participants for a productive day with
> insights about everyone's concerns and priorities. :-)
>
> Cheers,
> »Lucas
>
> On Mon, Nov 14, 2016 at 9:43 PM Emily Stark <[email-masked]> wrote:
>
>> Adding Lucas, who organized the meetup. I know he's planning to share
>> notes eventually though I don't know if they're ready for consumption
>> yet.
>>
>> On Tue, Nov 15, 2016 at 4:08 AM, John Wilander <[email-masked]>
>> wrote:
>> > Hi WebAppSec!
>> >
>> > I know there was an HSTS meetup in San Francisco on 9/30, organized by
>> > Google. Challenges with HSTS preload was one of the topics (see for
>> instance
>> > requests for removal). Could we get summary + any action points sent
>> here?
>> > Or maybe there’s already a thread on some other mailing list? Thanks!
>> >
>> > I know HSTS doesn’t fall under our working group but it relates with
>> UIR and
>> > we should follow what happens.
>> >
>> >    Regards, John
>>
>

-- 
Eric Mill
Senior Advisor on Technology
Technology Transformation Service, GSA
[email-masked], +1-617-314-0966 <(617)%20314-0966>

---

From: Anne van Kesteren <[email-masked]>
Date: Fri, 20 Jan 2017 19:52:19 +0100

On Fri, Jan 20, 2017 at 7:38 PM, Eric Mill <[email-masked]> wrote:
> It's a novel approach, and potentially could serve as a model for other TLDs
> or suffixes -- so if folks have any feedback or suggestions about this

Is the reverse not possible? Where everything .gov is HSTS, unless
it's on an HTTP-safelist? Or would that list still be way longer?

-- 
https://annevankesteren.nl/

---

From: Eric Mill <[email-masked]>
Date: Fri, 20 Jan 2017 14:30:39 -0500

On Fri, Jan 20, 2017 at 1:52 PM, Anne van Kesteren <[email-masked]> wrote:

> TLDs

The reverse is certainly possible, but not right away. This change
currently only includes a subset of the .gov user base -- executive branch
agencies, which currently represent ~1,100 of the total ~5,600 .gov
domains.

The .gov TLD is also used for legislative branch and judicial branch
agencies (~200 domains), as well as state, city, county, and other local
entities (~4,000 domains), as well as native tribal governments (~170
domains). (Estimates, the numbers don't add up exactly.)

If GSA at some point extends the practice to include those other entities,
it would then become feasible to tell browsers "preload *.gov, _except_ for
these X,X00 domains", where the X,X00 domains represent the existing legacy
non-preloaded .gov domains at that time across all parts of the user base.
Then the TLD could focus on just deleting legacy non-preloaded entries from
the list over time, instead of adding new entries to the list.

However, to take that kind of step, clients that use preload lists would
also need to support the idea of "carveouts". This has come up before for
second-level domains (e.g. preload "facebook.com" except for these old
subdomains), and there seemed to be pretty broad consensus that list
operators don't want to support that. It might be a different value
proposition if applied to top-level domains and public suffixes, though.

-- Eric

-- 
Eric Mill
Senior Advisor on Technology
Technology Transformation Service, GSA
[email-masked], +1-617-314-0966

---

From: "Hodges, Jeff" <[email-masked]>
Date: Fri, 20 Jan 2017 21:18:21 +0000

[ fwd'g on Lucas' behalf... ]

From:  Lucas Garron <[email-masked]>
Date:  Thursday, January 19, 2017 at 5:03 PM
To:  IETF WebSec List <[email-masked]>, W3C Web App Security WG
<[email-masked]>
Subject:  Notes from an HSTS Meetup (Sep. 2016)

Hi all,

Last September I organized HSTS meetup, and I'd like to share public notes
of what we discussed: bit.ly/hsts-meetup-notes
<https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrX
NBIbI/edit#>

Most major browsers had at least one participant, and since I currently
maintain the
Chromium HSTS preload list <https://hstspreload.org/>, I set roughly half
the agenda to discuss the HSTS preload list.

Some highlights:

* We collectively documented the HSTS preload list processes
<https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrX
NBIbI/edit#heading=h.gpm9zj53wbk5> for Mozilla, Microsoft, Chrome, Opera,
and Safari in one place for the first time. I also also made

slides documenting the Chromium preload list submission process:
<https://docs.google.com/presentation/d/1TdSPLBqkeSGZ3mFO6bSpHaRKKwPVDzU_xV
c7q5vdHrY/edit#slide=id.p>

* The HSTS preload list has roughly two major issues: stale/removed
entries, and potentially very large growth in the near future. To help
address this, most browsers could
 support out-of-band updates
<https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrX
NBIbI/edit#bookmark=id.5gjn9r3a8p80> if it becomes necessary. (In fact, it
seems Firefox
 just implemented this
<https://twitter.com/rlbarnes/status/819640097972822020>.)

* Firefox has implemented HSTS priming
<https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrX
NBIbI/edit#heading=h.vpdezmng8pxs>, which addresses the fact that HSTS on
its own does not prevent mixed content. Chrome is interested
 in implementing this, too. :-)

* Related topics: history of HSTS, HSTS history leaks and supercookies,
how to handle demand for content filtering when HTTPS is common, how to
get to a place where the web can be HTTPS by default, how to switch entire
TLDs to HTTPS, how to prevent developers
 from accidentally preloading.

(One planned topic that we didn't end up discussing much at the meetup was
standardizing the `preload` directive used by hstspreload.org
<http://hstspreload.org>)

Based on the discussions, I am also planning to make several changes to
https://hstspreload.org <https://hstspreload.org> in the near future:

* Automatically handle removal requests and prune stale entries
<https://bugs.chromium.org/p/chromium/issues/detail?id=608599> using
daily scans <https://github.com/chromium/hstspreload.org/issues/35>.

* Once we're confident about pruning process keeps the list up-to-date,
get all browsers to draw from the same source of truth
<https://github.com/chromium/hstspreload.org/issues/76> instead of
filtering each other's lists. (This can reduce delays for new/removed
entries by several months.)

* Possibly raise the submission requirements
<https://hstspreload.org/#submission-requirements> to a minimum max-age of
1 year 
<https://docs.google.com/document/d/1d21wtTCQ-a6vN7yDwyhLkuBpgmLoJCKMI7aRrX
NBIbI/edit#bookmark=id.s9cg5xbp1r1m>.

martijnc@ has also been contributing changes
<https://bugs.chromium.org/p/chromium/issues/detail?id=595493> to Chromium
that will make my life as maintainer easier. :-)

Apologies for the delay if anyone was waiting on this. I had a lot of
non-HSTS work to do last quarter, but I've started work on hstspreload.org
<http://hstspreload.org> for the bullet points above, and plan to dedicate
a significant amount to this in early 2017.

Cheers,
»Lucas

On Tue, Nov 15, 2016 at 4:08 AM, John Wilander <[email-masked]> wrote:
> Or maybe there¹s already a thread on some other mailing list? Thanks!
>
> I know HSTS doesn¹t fall under our working group but it relates with UIR
>and