Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45687129C5A for ; Fri, 20 Jan 2017 10:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsa.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgYkRwLZJ6Ko for ; Fri, 20 Jan 2017 10:39:08 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D94A129C56 for ; Fri, 20 Jan 2017 10:39:07 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id w75so97973753ywg.1 for ; Fri, 20 Jan 2017 10:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gsa.gov; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xZQBXSs6EjWwvShftqHZZ3Zq37ikTZu5/sY31Dg1zKo=; b=EiWlQVcuijyGKyWeuG3vxp/SqkNseVsh24yPE417/opbZtmSMYenMOwBRF7/ZgqFoW eBb64S9K1KKKEHGyKpi+M7yb196DuEMmcsphzx+Z+6AkTK0vH6HbZ43UzJg8smi5u+wC caxbWbgqRGBPufX7ZkA1PtiHZr4+VQcfVzl3E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xZQBXSs6EjWwvShftqHZZ3Zq37ikTZu5/sY31Dg1zKo=; b=Nl3dqVXd144ZA1c5pjorzwzVFmHYtkHL1W2VH5ZaOXq9CZN19/0PbgGK3AqEQe02RO K2EtO7sclvB9fuV7lF78qRNEcFUOnTDelJm1N5EoY4p3PLZ/gPDaydznxLwgTlLKNgQS kJHSsRasK/QhngydF2KxVc6rQ3bDfcpuRINUoIRmirmFCzMLJlojhhXvUYCaClUHJRTL 83BJz5a5Lj//uHodGEPzmLLHJu0x+sfkmdSZ8+2AHdMLe5IDP649x0Xzy/EVu/vdelWl cE+CMMRsSc8DqZjW4m4p3A/dfW9tB9jT9dYAFzovCZoVHFq1TRHZ5E68KWpv/ddceTu6 YEig== X-Gm-Message-State: AIkVDXLkYbIklfQQVKbOuRiY4wZ5KqmJGBEzzIf+0B/BNUqIt7zZHqhkWQWKPR1r3xjk+t5ug8ixXv0PceFPAm9l X-Received: by 10.55.70.82 with SMTP id t79mr13224063qka.82.1484937546638; Fri, 20 Jan 2017 10:39:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.180.65 with HTTP; Fri, 20 Jan 2017 10:38:26 -0800 (PST) In-Reply-To: References: <79E2F435-E9A0-4F54-8F01-6A3CB21E2F0E@apple.com> From: Eric Mill Date: Fri, 20 Jan 2017 13:38:26 -0500 Message-ID: To: Lucas Garron Content-Type: multipart/alternative; boundary=001a11488db0fbf2cb05468af617 Archived-At: Cc: "public-webappsec@w3.org" , websec@ietf.org Subject: Re: [websec] Notes from an HSTS Meetup (Sep. 2016) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:41:26 -0000 --001a11488db0fbf2cb05468af617 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=9Cpreloading=E2=80=9D. After submiss= ion, 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 wrote: > Hi all, > > Last September I organized HSTS meetup, and I'd like to share public note= s > of what we discussed: bit.ly/hsts-meetup-notes > > > Most major browsers had at least one participant, and since I currently > maintain the Chromium HSTS preload list , I set > roughly half the agenda to discuss the HSTS preload list. > > Some highlights: > > - We collectively documented the HSTS preload list processes > > 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. > > - 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 > > if it becomes necessary. (In fact, it seems Firefox just implemented > this .) > - Firefox has implemented HSTS priming > , > 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, h= ow to > switch entire TLDs to HTTPS, how to prevent developers from accidental= ly > preloading. > > (One planned topic that we didn't end up discussing much at the meetup wa= s > 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 > using= daily > scans . > - Once we're confident about pruning process keeps the list > up-to-date, get all browsers to draw from the same source of truth > instead of > filtering each other's lists. (This can reduce delays for new/removed > entries by several months.) > - Possibly raise the submission requirements > to a minimum > max-age of 1 year > > . > > martijnc@ has also been contributing changes > 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.or= g > 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, > =C2=BBLucas > > On Mon, Nov 14, 2016 at 9:43 PM Emily Stark 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 >> 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=E2=80=99s already a thread on some other mailing list? = Thanks! >> > >> > I know HSTS doesn=E2=80=99t fall under our working group but it relate= s with >> UIR and >> > we should follow what happens. >> > >> > Regards, John >> > --=20 Eric Mill Senior Advisor on Technology Technology Transformation Service, GSA eric.mill@gsa.gov, +1-617-314-0966 <(617)%20314-0966> --001a11488db0fbf2cb05468af617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a follow-up to the part of the notes about .gov, and po= tentially using the HSTS preload list as a migration pathway -- that's = what the .gov domain program (an office of GSA) announced yesterday:

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 th= at we feel confident enough won't break anything.=C2=A0

<= /div>
The relevant excerpt:

This year, G= SA will be taking another significant step forward in making secure communi= cation the default for federal web services by automatically enforcing H= TTPS in modern web browsers for newly issued executive branch .gov d= omains and their subdomains.

As new executive = branch domains are registered, the dotgov.gov program will submit them to web browsers for =E2=80= =9Cpreloading=E2=80=9D. After submission, it can take up to three months be= fore preloading takes effect in modern web browsers. The change will be int= roduced to dotgov customers when they register a new domain under the Execu= tive Branch, and will not affect existing or renewed domains.
<= div>
Once preloading is in effect, browsers will strictly enf= orce HTTPS for these domains and their subdomains. Users will not be able t= o click through certificate warnings. Any web services on these domains wil= l need to be accessible over HTTPS in order to be used by modern web browse= rs.

We'll be finalizing the mech= anics of how .gov programmatically sends entries to the preload list with L= ucas and his team over the next month.=C2=A0

It= 9;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 eff= ort, it'd be welcome and timely.

-- Eric
=

On Thu, Jan 19, 2= 017 at 8:03 PM, Lucas Garron <lgarron@google.com> wrote:
Hi all,
Last September I organized HSTS meetup, and I'd like to sha= re public notes of what we discussed:=C2=A0bit.ly/hsts-meetup-notes

Most ma= jor browsers had at least one participant, and since I currently maintain t= he Chromium HSTS pre= load list, I set roughly half the agenda to discuss the HSTS preload li= st.

Some highlights:
  • We collecti= vely docum= ented the HSTS preload list processes for Mozilla, Microsoft, Chrome, O= pera, and Safari in one place for the first time. I also also made slides documenting the Ch= romium preload list submission process.
  • The HSTS preload li= st has roughly two major issues: stale/removed entries, and potentially ver= y large growth in the near future. To help address this, most browsers=C2=A0could support out-of-band updates= =C2=A0if it becomes necessary. (In fact, it seems= =C2=A0Firefox just implemented this.)
  • Firefox = has implemented=C2=A0HSTS priming, 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 s= upercookies, how to handle demand for content filtering when HTTPS is commo= n, how to get to a place where the web can be HTTPS by default, how to swit= ch entire TLDs to HTTPS, how to prevent developers from accidentally preloa= ding.
(One planned topic that we didn't end up= discussing much at the meetup was standardizing the `preload` directive us= ed by hstspreload.org<= /a>)

=
martijnc@ has also been contributing changes 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 las= t 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 d= ay with insights about everyone's concerns and priorities. :-)

Cheers,
=C2=BBLucas

On Mon, Nov 14, 2016 at 9:43 PM Emily Stark <estark@google.com>= ; wrote:
Adding Lucas, who organize= d the meetup. I know he's planning to share
notes eventually though I don't know if they're ready for consumpti= on
yet.

On Tue, Nov 15, 2016 at 4:08 AM, John Wilander <wilander@apple.com> 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 in= stance
> requests for removal). Could we get summary + any action points sent h= ere?
> Or maybe there=E2=80=99s already a thread on some other mailing list? = Thanks!
>
> I know HSTS doesn=E2=80=99t fall under our working group but it relate= s with UIR and
> we should follow what happens.
>
>=C2=A0 =C2=A0 Regards, John



--
Eric Mill
Senior Advisor on Technology
Technology Transformation Service, GSA
--001a11488db0fbf2cb05468af617--