On Tue, May 8, 2018 at 3:47 AM, Anne van Kesteren <[email protected]> wrote:
> On Mon, May 7, 2018 at 9:54 PM, Yoav Nir <[email protected]> wrote: > > Immutable meaning that the HSTS header is permanent and can never be > > removed? So if a user agent has seen an immutable HSTS header once, that > > site has to be (valid) HTTPS-only forever? > > > > Interesting idea. > > FWIW, if anything, it should be about standardizing > https://hstspreload.org/. That's already the widely adopted practice > to mostly-immutable HSTS. (Not quite sure truly-immutable is feasible, > other than using a TLD that has HSTS as policy. And even then TLDs get > reassigned or disappear at times...) > There is a list that could be used to discuss that, run by Chrome but with members from other browsers: https://groups.google.com/a/chromium.org/forum/#!forum/hsts-discuss I also discussed some ideas with Lucas Garron (then on the Chrome team) in late 2016 / early 2017 about how to standardize a way for public suffixes to automatically request preloading, which we sketched out here: https://docs.google.com/document/d/1fngkzHVBRRzYKWgiKDiUrOqWDUkDBbbTXAbo4BHEAoI/edit#heading=h.au203bjfkch0 In the end we didn't do anything sophisticated or standard, and instead ..gov just emails new domains in small, regular batches to Chrome and Firefox for preloading. But moving the preloading process towards standardization seems like it would be positive for everyone. -- Eric > > -- > https://annevankesteren.nl/ > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > > -- Eric Mill Senior Advisor, Technology Transformation Services Federal Acquisition Service, GSA [email protected], +1-617-314-0966
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
