Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Deployment Recommendations section regarding max-age 2 years #258

Open
vishalgiri opened this issue Apr 22, 2024 · 2 comments
Open

Comments

@vishalgiri
Copy link

The Submission Requirements are very clear.
The max-age must be at least 31536000 seconds (1 year).

As part of

There were a few thoughts there:

  • "(And if you visit a site less than once per year, the benefit from trying to protect recurrent visits is more questionable. But maybe this should be 2 years for yearly events that can shift seasons?)" and "Matches my thoughts exactly. How common is 2 years? Could you post the distribution here?" by @lgarron
  • ...chrome (and maybe FF too?) enforces max max-age of 1 year, so not sure if a recommendation of 2 years makes sense by @estark37

I really like the overall advice and suggestions about the approach that one should follow.
However, regarding 2 years max-age from the preload point of view:

  • It does not provide any additional benefits or difference.
  • As far as I know, domain name registration should not have any direct relation to HSTS max-age, however, since we are preloading domain name in browser's source code, in one case, previous owner may preload, and new owner can submit for removal if new owner wanted. (Nobody should do that and http over plain text should be deprecated with a fixed date in the future). However, my point is domain name does not seem to be related in a favorable way to https.
  • Once preloaded, unless it is removed (by using the removal request form), preload will be effective forever (though headers should not be removed so malicious actor cannot request removal as already mentioned in Continued Requirements
  • So, after setting max-age for 1 year, and getting it preloaded, having it for 2 years or more should not make any difference. Though I agree it does not cause any issues except for some inconvenience mentioned below

Inconvenience and Lack of correct understanding by industry:

MDN:
"Although a max-age of 1 year is acceptable for a domain, two years is the recommended value as explained on https://hstspreload.org/.

In the following example, max-age is set to 2 years, and is suffixed with preload, which is necessary for inclusion in all major web browsers' HSTS preload lists, like Chromium, Edge, and Firefox."

Please note the part "which is necessary for inclusion..."

Apart from MDN contributors, there are other commercial security scan tools has started using 2 years max-age as a necessity (requirement) to get domain preloaded. Some security scan tools even give an incorrect score just based on 1 year max-age, even in case if the domain including subdomain is already in the preload list for a long time.

Many people in industry are confused about preload being part of RFC 6797 which is not the case. And the 2 year mention just adds to the confusion.

Suggestion:

  • We should change the Deployment Recommendations section and for point 3 we should mention 1 year along with example with 1 year.

Please clarify if my overlooked anything. Or didn't understand the reason behind 2 years max-age in regards to preload.

@lgarron
Copy link
Collaborator

lgarron commented Apr 22, 2024

This disagreement was never resolved. I still personally maintain that there are enough use cases for sites that people visit roughly but not exactly once a year. A cap of 365 days would be just a little too short to provide protection, whereas two years does.

Regarding preload never being specified, I didn't have time to get that done while I was at Google. I'd still love to do it, but I have too much other day work and open-source work to dedicate time to that. I don't know if there are any other active plans.

@vishalgiri
Copy link
Author

@lgarron Thank you for responding, your contributions has helped countless users all over the world.

I understand, this is mainly for scenarios where, browsers storing known HSTS host or longer duration would benefit, in case if the user does not update their browser for a year or more. And has once visited the site to get the domain added to Dynamic STS host list. And it is regardless of if a domain name is included in preload (static) list or not.

It does not make much difference, if a domain has been on preload list for a couple of years, in that case most likely user is running a browser with that domain already on the preload (static sts host).

As we know preload only helps if users keep their browser up to date, and in the cases when user visit a site for the first time and browser having preloaded list of domains can protect user even for those first time visits.

I think we can close this ticket unless there are any other comments or thoughts.
I will open a separate ticket to get MDN updated, so there is no confusion about 2 years being a necessity to get domain preloaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants