From eric.mill@gsa.gov Fri Jan 20 10:39:11 2017 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-- From nobody Fri Jan 20 10:52:23 2017 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 0EA82129C63 for ; Fri, 20 Jan 2017 10:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl 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 42YJqUwODkve for ; Fri, 20 Jan 2017 10:52:21 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3010A129C5F for ; Fri, 20 Jan 2017 10:52:21 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 94A2210AFBD for ; Fri, 20 Jan 2017 10:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc: content-type; s=annevk.nl; bh=IMPs1RLyn++PafCzjMgi4RZVLgo=; b=IJ QlQ/bvSk7zS68ds5MNaDoqo8rVfnvV2lDn84FLjak1owd3Dl7Tq2q9c3I5DW69qJ vwJBENn3F4KgvuEuTxIfSHlFSo3uYJdzh1xghwGsRSMLr5+LkEEJukv8U9FCtcsZ nw9CMWbB0lvjiKbPjkZCkcsdgTo2ogt5I4ONfWUmY= Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.161.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 74BB510AFB8 for ; Fri, 20 Jan 2017 10:52:20 -0800 (PST) Received: by mail-yw0-f181.google.com with SMTP id v200so98369261ywc.3 for ; Fri, 20 Jan 2017 10:52:20 -0800 (PST) X-Gm-Message-State: AIkVDXL4yivMil98EyA5NoA3rBFNjTYoCAjKw/w18s1DZPty04PK7xHNgCE9yBFvIPq3MXpovRDxYn5KMvhGJA== X-Received: by 10.13.218.195 with SMTP id c186mr13036871ywe.15.1484938339672; Fri, 20 Jan 2017 10:52:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.90 with HTTP; Fri, 20 Jan 2017 10:52:19 -0800 (PST) In-Reply-To: References: <79E2F435-E9A0-4F54-8F01-6A3CB21E2F0E@apple.com> From: Anne van Kesteren Date: Fri, 20 Jan 2017 19:52:19 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Eric Mill Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "public-webappsec@w3.org" , Lucas Garron , websec 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:52:22 -0000 On Fri, Jan 20, 2017 at 7:38 PM, Eric Mill 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 > effort, it'd be welcome and timely. 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@gsa.gov Fri Jan 20 11:31:24 2017 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 DACE61293F4 for ; Fri, 20 Jan 2017 11:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 f6PI8ZxrdkZM for ; Fri, 20 Jan 2017 11:31:21 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 B2EC9128874 for ; Fri, 20 Jan 2017 11:31:21 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id w194so67983389ybe.0 for ; Fri, 20 Jan 2017 11:31:21 -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=AeWZGp9pGwaymgV6BqOuknMOj00LI8p0EN9jyMmSRrc=; b=Q8WBZQQdGiQW8AHh0gmPWwRz1mytzsYV37Gwmcq5uXdefG80WIr/pLDqJRyRLlD0TT M0z1Cma7oMXgIe/l7GXlZy+EwiQRVgbBzMN+0mxXiNn7KZ2n80G5n20FkS6B8mF0m0uO MKDrV6zjkl0h1Q+R1pSAh8DrlC8+Kv9k3OuIA= 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=AeWZGp9pGwaymgV6BqOuknMOj00LI8p0EN9jyMmSRrc=; b=OuT7CBuifV85casUgGDiG4TvkfVXAqrNODEsXDNjpnruR5c66Obh6D6JGSzCsANymy ZtR8fLZv8EaBlueTz0tPIluG1oiAzTNIqOBu4UU0+Av+vpr4F3lBTaQsEfc3Y+nYBt3V cR7+oCwIBxNouocbDS9IpoHMIqzgTy1bWWVQro4RbhGJt1bEHGC8O8Oi6cmnw3WtDfQA pkwnmH9DuryvJlQo20EM9QDA0JB2AqdNVi0r5kvoA1eoZbHCTy/qLEjHJNu/6TW4Zdd8 8Sy4xlpVBn7zoYEbu0JxeQGUrakkK2JogE+1RVLQvRsm6j9r8GEmDurLRiywnf4n5BLR BwvQ== X-Gm-Message-State: AIkVDXJfq1Iul/3aAlfX6F82RYz3hmncvJGi5VMIy/VO/Jv/0Z5n/RXnMsXU+D+WpOFR34k3kYxozc60i+RNInrb X-Received: by 10.200.41.198 with SMTP id 6mr13655293qtt.130.1484940680409; Fri, 20 Jan 2017 11:31:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.180.65 with HTTP; Fri, 20 Jan 2017 11:30:39 -0800 (PST) In-Reply-To: References: <79E2F435-E9A0-4F54-8F01-6A3CB21E2F0E@apple.com> From: Eric Mill Date: Fri, 20 Jan 2017 14:30:39 -0500 Message-ID: To: Anne van Kesteren Content-Type: multipart/alternative; boundary=001a1141068cc56be405468bb195 Cc: "public-webappsec@w3.org" , Lucas Garron , websec 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 19:31:25 -0000 --001a1141068cc56be405468bb195 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 20, 2017 at 1:52 PM, Anne van Kesteren wrote: > On Fri, Jan 20, 2017 at 7:38 PM, Eric Mill 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 > > effort, it'd be welcome and timely. > > 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? > 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 > > -- > https://annevankesteren.nl/ > -- Eric Mill Senior Advisor on Technology Technology Transformation Service, GSA eric.mill@gsa.gov, +1-617-314-0966 --001a1141068cc56be405468bb195 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 20, 2017 at 1:52 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
On Fri, Jan 20, 2017 at 7:38 PM, Eric Mill <eric.mill@gsa.gov> 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=
> effort, it'd be welcome and timely.

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?

The reverse is certainly possible, but not r= ight away. This change currently only includes a subset of the .gov user ba= se -- executive branch agencies, which currently represent ~1,100 of the to= tal ~5,600 .gov domains.=C2=A0

The .gov TLD is als= o 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 number= s don't add up exactly.)

If GSA at some po= int extends the practice to include those other entities, it would then bec= ome feasible to tell browsers "preload *.gov, _except_ for these X,X00= domains", where the X,X00 domains represent the existing legacy non-p= reloaded .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 com= e 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 wan= t to support that. It might be a different value proposition if applied to = top-level domains and public suffixes, though.

-- = Eric



--
https://annevankesteren.nl/



--
Eric Mill
= Senior Advisor on Technology
Technology Transformation Service, G= SA
eric.mill@gsa.gov,=C2=A0+1-617-314-096= 6
--001a1141068cc56be405468bb195-- From nobody Fri Jan 20 13:05:18 2017 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 BF533129483 for ; Fri, 20 Jan 2017 13:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZBph1UtNgln3 for ; Fri, 20 Jan 2017 13:05:15 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 7961C129481 for ; Fri, 20 Jan 2017 13:05:15 -0800 (PST) Received: (qmail 31903 invoked by uid 0); 20 Jan 2017 21:05:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 20 Jan 2017 21:05:05 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id al4d1u00R2UhLwi01l4gmX; Fri, 20 Jan 2017 14:04:40 -0700 X-Authority-Analysis: v=2.1 cv=YuCcGeoX c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=IgFoBzBjUZAA:10 a=nS36O97Bj3wUElCrIrAA:9 a=QEXdDO2ut3YA:10 Received: from [173.224.162.69] (port=8867 helo=[10.225.80.43]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUgMP-0004ad-0i for websec@ietf.org; Fri, 20 Jan 2017 14:04:37 -0700 To: websec@ietf.org From: =JeffH Message-ID: <7c1fc0ea-3cf0-7974-0992-535eef45e993@KingsMountain.com> Date: Fri, 20 Jan 2017 13:04:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1cUgMP-0004ad-0i X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.43]) [173.224.162.69]:8867 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [websec] test 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 21:05:17 -0000 test From nobody Fri Jan 20 13:18:27 2017 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 5596B129495 for ; Fri, 20 Jan 2017 13:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.com 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 CuPfgyr5Im85 for ; Fri, 20 Jan 2017 13:18:23 -0800 (PST) Received: from den-ipout-02-data1.paypalcorp.com (den-ipout-02-data1.paypalcorp.com [173.224.160.155]) (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 B8D23129494 for ; Fri, 20 Jan 2017 13:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1484947103; x=1516483103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1USOKuxxN2gl/XaxrLAOBNIUL8/6WTRwoouemb+5R4k=; b=wQG1UvF3TUCbVrJ3VMT5oFqXbscKxtvRbUHWIX2P6GhLePIjNl3PUsNg Qhcuiv8WyZiPE74mu0sxl8XnMW1y7jOxh9eiB9m74pXJVWWSeqiz+2fOW guR3tpDaj3gq9AXamZ9IBJA+z6Kdoyy+Q+labYpIWAYFZillqb2uXSTGT Ty62GYrnyw6VhZkFcRu/ilgP2SHIZ8UraCGl+Mh8ALbfmXli0zrGaJQbV iTIKMOh4pErmVcOX0thOOvAw1VWGEiePDJyGe1riI8s0lBKT7QU+59EHg ZUJfcw+JtKPY/GR62RB8qEychC7SsCa0q+pU5b98Eri6k4t3OS13Jq7py Q==; X-IronPort-AV: E=Sophos;i="5.33,260,1477980000"; d="scan'208";a="32366751" Received: from unknown (HELO lvs-ipcld-01-data1.paypalcorp.com) ([10.184.246.167]) by den-ipout-02-data1.paypalcorp.com with ESMTP; 20 Jan 2017 14:18:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,260,1477983600"; d="scan'208";a="11149990" X-CloudService: Office365 Received: from mail-by2nam03lp0053.outbound.protection.outlook.com (HELO NAM03-BY2-obe.outbound.protection.outlook.com) ([216.32.180.53]) by lvs-ipcld-01-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 20 Jan 2017 13:18:14 -0800 Received: from SN1PR06MB2094.namprd06.prod.outlook.com (10.169.125.142) by SN1PR06MB2093.namprd06.prod.outlook.com (10.169.125.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 20 Jan 2017 21:18:21 +0000 Received: from SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) by SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) with mapi id 15.01.0845.013; Fri, 20 Jan 2017 21:18:21 +0000 From: "Hodges, Jeff" To: IETF WebSec List Thread-Topic: Notes from an HSTS Meetup (Sep. 2016) Thread-Index: AQHScrkNj++wntf9SEWWePeuAjazYaFBWeCA Date: Fri, 20 Jan 2017 21:18:21 +0000 Message-ID: References: <79E2F435-E9A0-4F54-8F01-6A3CB21E2F0E@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.224.162.69] x-ms-office365-filtering-correlation-id: a968ef60-7667-46fb-88a3-08d44179dc99 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR06MB2093; x-microsoft-exchange-diagnostics: 1; SN1PR06MB2093; 7:36ChuoBJAoKr9A3ER1A0FyCpfOVdUds8hjvmpHsn9tv785h/xbFbY9DVzLr6nSE+4uhNsnxL67fGKIPYz8ZXCxGw3FVrQTWsQ3EwdoZUZvhDWr0R+6zYvtmCu5at3iyt4UmiULkcjemBQUlaxnnzGCgEqtyCq02UScPWAmkSsZb//B5oMieSFanB8nN0SdHxQD3O8SD1nHLkOR2gyX6LqPu0oda/IKuhEsjVniraNRNB26lgUlPOvL12CU8ExeG4do1cVsYU+qkS026CFK1s2YiiXEQcZPc/ruTAoXtaihzho2VkudHtjoDSF4RXuTxPsb97OItO38GSfzfj4PjkNmaJ0+VpVJkZWBxSx17unjwfMqXSbegBM49oRaZOSg4P2r52nC1CN3nhxYzrW9PQCub74oj6yGqALZqiFp6+lAiXQN5CG4/WI7fokSQP/J+2X/I6up3l+1IfkggMUSpLAA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(31418570063057)(211936372134217)(31960201722614)(148717330147763)(119230021023882); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:SN1PR06MB2093; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB2093; x-forefront-prvs: 01930B2BA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39850400002)(39410400002)(39860400002)(69224002)(66654002)(377454003)(24454002)(189002)(53754006)(199003)(2950100002)(2906002)(6306002)(3846002)(110136003)(8936002)(66066001)(6436002)(4001350100001)(5660300001)(82432001)(81166006)(4500500003)(83506001)(101416001)(25786008)(5002510100001)(77096006)(305945005)(77072002)(189998001)(6486002)(102836003)(86362001)(3660700001)(8676002)(97736004)(99286003)(7736002)(6116002)(10130500003)(73692002)(81156014)(2900100001)(6512007)(38730400001)(10770500004)(9686003)(10300500001)(4326007)(106116001)(6506006)(106356001)(105586002)(10290500002)(68736007)(92566002)(50986999)(36756003)(122556002)(6916009)(54356999)(76176999)(53936002)(3280700002)(10630500005)(56826009)(493534005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR06MB2093; H:SN1PR06MB2094.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4771A7887A82E349B253672569D10E1D@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2017 21:18:21.2574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB2093 X-CFilter: Scanned den1 Archived-At: Cc: Lucas Garron Subject: [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 21:18:25 -0000 [ fwd'g on Lucas' behalf... ] From: Lucas Garron Date: Thursday, January 19, 2017 at 5:03 PM To: IETF WebSec List , W3C Web App Security WG 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 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, i= t 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, 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 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=20 . martijnc@ has also been contributing changes to Chromiu= m 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, =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=B9s already a thread on some other mailing list? Thanks! > > I know HSTS doesn=B9t fall under our working group but it relates with UI= R >and > we should follow what happens. > > Regards, John