Subject: [websec] Regarding RFC 6797

From: Robert Linder <[email-masked]>
Date: Fri, 4 May 2018 20:11:53 +0000

Hi,

I would like to propose the addition of the ”immutable” directive (similar to that of RFC 8246) for the HSTS header field (RFC 6797).

Best Regards,
Robert Linder

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 May 2018 22:54:59 +0300

> On 4 May 2018, at 23:11, Robert Linder <[email-masked]> wrote:
> 
> Hi,
> 

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.

Anyway, the WebSec working group has been closed for several years now.  If you would like to extend HSTS, you should submit an individual draft (something with a name like draft-linder-hsts-immutable-00).

You can then discuss the draft either here or in the secdispatch mailing list (more technical discussion goes here; procedural discussion goes there).

You can also ask to present your draft at the meeting of the SecDispatch working group at the next IETF meeting (this July in Montreal, or the one after that: November in Bangkok). The purpose of the SecDispatch working group is to recommend what to do with new drafts - either spin up a new working group, or find an existing working group to work on this, or ask an Area Director to sponsor the draft as an individual submission.

Hope this helps

Yoav
(former co-chair of WebSec)

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 8 May 2018 09:47:57 +0200

On Mon, May 7, 2018 at 9:54 PM, Yoav Nir <[email-masked]> 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...)

-- 
https://annevankesteren.nl/

---

From: Eric Mill <[email-masked]>
Date: Tue, 8 May 2018 14:17:38 -0400

> 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

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

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

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 14 May 2018 17:59:47 +0200

I agree. Preload is probably the easiest way to go. 
And the use case of transfer of domain ownership can not be ignored. 

Not sure whether preload really needs further standardization, after all
there are only a few browser implementations out there. 
However, if you think that is needed, feel free to drop me a message and we
can write up a quick ID and publish it as individual ID. 

Best regards, Tobias

-----Original Message-----
From: websec <[email-masked]> On Behalf Of Anne van Kesteren
Sent: Tuesday, May 8, 2018 9:48 AM
To: Yoav Nir <[email-masked]>
Cc: Robert Linder <[email-masked]>; [email-masked]
Subject: Re: [websec] Regarding RFC 6797

On Mon, May 7, 2018 at 9:54 PM, Yoav Nir <[email-masked]> wrote:
> 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...)

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 14 May 2018 18:32:06 +0200

> can write up a quick ID and publish it as individual ID.

I think it'd be good to formalize that the preload keyword is used,
cannot be used for something else, and what it's used for.

---

From: "Tobias Gondrom" <[email-masked]>
Date: Tue, 15 May 2018 10:50:31 +0200

-----Original Message-----
From: Anne van Kesteren <[email-masked]> 
Sent: Monday, May 14, 2018 6:32 PM
To: Tobias Gondrom <[email-masked]>
Cc: Yoav Nir <[email-masked]>; Robert Linder <[email-masked]>; websec <[email-masked]>
Subject: Re: [websec] Regarding RFC 6797

>On Mon, May 14, 2018 at 5:59 PM, Tobias Gondrom <[email-masked]> wrote:
>> Not sure whether preload really needs further standardization, after 
>> all there are only a few browser implementations out there.
>> However, if you think that is needed, feel free to drop me a message 
>> and we can write up a quick ID and publish it as individual ID.

> I think it'd be good to formalize that the preload keyword is used, cannot be used for something else, and what it's used for.

Do you think we need for this an individual RFC or would there be any simpler way we could achieve this? 
Best regards, Tobias

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 15 May 2018 11:00:41 +0200

> Do you think we need for this an individual RFC or would there be any simpler way we could achieve this?

You need an RFC that updates the existing RFC as there's no other
extension path provided.

---

From: Eitan Adler <[email-masked]>
Date: Tue, 22 May 2018 22:48:32 -0700

> can write up a quick ID and publish it as individual ID.

What ever happened to this? It can be valuable to standardize preloading.

-- 
Eitan Adler