Closed Bug 1012875 Opened 5 years ago Closed 5 years ago

Reduce pinset lifetime to 8 weeks once it reaches stable

Categories

(Core :: Security: PSM, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla33
Tracking Status
firefox32 --- fixed
firefox33 --- fixed

People

(Reporter: mmc, Assigned: mmc)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Chrome's is at 10 weeks, and they asked us to reduce ours.
The question is, 10 weeks from when? Ours is currently 18 weeks. However, if the last time we update it is just before the merge from Nightly to Aurora, then those pins will expire 6 weeks after that version is released as a stable Firefox version.
Once bug 1004279 is resolved, then it will be x weeks from the release build date. I think that's the correct starting time.
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #0)
> Chrome's is at 10 weeks, and they asked us to reduce ours.

Can you rope us in (even OOB) on this conversation?
(In reply to Camilo Viecco (:cviecco) from comment #3)
> (In reply to [:mmc] Monica Chew (please use needinfo) from comment #0)
> > Chrome's is at 10 weeks, and they asked us to reduce ours.
> 
> Can you rope us in (even OOB) on this conversation?

Forwarded.
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #4)
> (In reply to Camilo Viecco (:cviecco) from comment #3)
> > (In reply to [:mmc] Monica Chew (please use needinfo) from comment #0)
> > > Chrome's is at 10 weeks, and they asked us to reduce ours.
> > 
> > Can you rope us in (even OOB) on this conversation?
> 
> Forwarded.

I am also interested in what Google had to say about pinning, since the last communication I had with them was them begging us not to pin any Google properties at all. It sounds like you have found a way to make them more comfortable with us pinning them, which is great, but it would be great to know what they actually think.

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #2)
> Once bug 1004279 is resolved, then it will be x weeks from the release build
> date. I think that's the correct starting time.

I disagree. Except for exceptional circumstances, whatever pins we're thinking to ship in the version X release channel should be tested in throughout version X beta channel, like we do for HSTS. (I think the HSTS preload list is automatically updated on the Aurora branch too, right?) IIRC, in the HSTS logic we save the date that the HSTS preload list was generated and then we calculate the expiration date as 18 weeks from that point in time. IMO, it would be good to be consistent in the absence of strong motivation for being inconsistent.
> I disagree. Except for exceptional circumstances, whatever pins we're
> thinking to ship in the version X release channel should be tested in
> throughout version X beta channel, like we do for HSTS. (I think the HSTS
> preload list is automatically updated on the Aurora branch too, right?)
> IIRC, in the HSTS logic we save the date that the HSTS preload list was
> generated and then we calculate the expiration date as 18 weeks from that
> point in time. IMO, it would be good to be consistent in the absence of
> strong motivation for being inconsistent.

I think I'm misunderstanding when the generator scripts are running. Are you saying that we should not update the expiration time every time there's a new Aurora or Beta release?
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #6)
> I think I'm misunderstanding when the generator scripts are running. Are you
> saying that we should not update the expiration time every time there's a
> new Aurora or Beta release?

1. We should update the expiration time when we've tested that we are able to connect to all the pinned sites given that pinset to be X (which could be debated) weeks from the time the test was run.

2. We should avoid updating the pinset after Aurora merges to Beta, except to address compatibility issues found during beta testing, so that the pinset is thoroughly tested by beta channel users prior to release.

In the case of HSTS preloads, we implicitly test compatibility as part of building the preload list (except for Google), so we already do #1 for that (except for Google). I'm not sure if/when/how we are automatically testing that we are able to successful connect to the pinned websites with the pins in effect. It seems like that part may be missing? This is the part that I think should update the time from which we base the expiration time.
> 1. We should update the expiration time when we've tested that we are able
> to connect to all the pinned sites given that pinset to be X (which could be
> debated) weeks from the time the test was run.
> 
> 2. We should avoid updating the pinset after Aurora merges to Beta, except
> to address compatibility issues found during beta testing, so that the
> pinset is thoroughly tested by beta channel users prior to release.

Agreed.

> In the case of HSTS preloads, we implicitly test compatibility as part of
> building the preload list (except for Google), so we already do #1 for that
> (except for Google). I'm not sure if/when/how we are automatically testing
> that we are able to successful connect to the pinned websites with the pins
> in effect. It seems like that part may be missing? This is the part that I
> think should update the time from which we base the expiration time.

I just chatted with keeler over irc. He says, the current behavior for HSTS is that the generator runs weekly on both m-c and aurora, so an 18 week expiration period means that the HSTS preload list is valid for around 12 weeks once it hits stable.

For pinning, Chrome has asked us to reduce this to 10 weeks, preferably 8. I also filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1004798 a while back to do continuous testing on pinned sites.
Summary: Reduce pinset lifetime to 10 weeks → Reduce pinset lifetime to 8 weeks once it reaches stable
Attached patch expireSplinter Review
Assignee: nobody → mmc
Attachment #8432818 - Flags: review?(cviecco)
Comment on attachment 8432818 [details] [diff] [review]
expire

Review of attachment 8432818 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, but I cannot r+ this change until bug 1004279 is done.
Attachment #8432818 - Flags: feedback+
Attachment #8432818 - Flags: review?(cviecco)
Comment on attachment 8432818 [details] [diff] [review]
expire

Review of attachment 8432818 [details] [diff] [review]:
-----------------------------------------------------------------

Bug 1004279 is done. We already need to ask for aurora uplift for this. I think Camilo's out.
Attachment #8432818 - Flags: review?(dkeeler)
Comment on attachment 8432818 [details] [diff] [review]
expire

Review of attachment 8432818 [details] [diff] [review]:
-----------------------------------------------------------------

Good to go.
Attachment #8432818 - Flags: review?(dkeeler) → review+
Approval Request Comment
[Feature/regressing bug #]: We did not have buildbot integration for updating pinset expiration dates in Nightly and Aurora until Bug 1004279 (just now). If Aurora is getting updated by the buildbot, then pins will expire 12 weeks from stable release instead of 8 as intended.

[User impact if declined]: Pins will expire 12 weeks from stable release of FF 32 instead of 8.

[Describe test coverage new/current, TBPL]: Existing unittest coverage in security/manager/ssl/tests/unit/test_pinning.js and production monitoring at people.mozilla.org/~mchew/pinning_dashboard/.

[Risks and why]: Relatively low risk.

[String/UUID change made/needed]: None.
Attachment #8449660 - Flags: approval-mozilla-aurora?
Attachment #8449660 - Attachment description: expire.txt → aurora-specific patch (only includes MAX_AGE changes, not changes to the generated file)
https://hg.mozilla.org/mozilla-central/rev/c93e297aaaf1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Comment on attachment 8449660 [details] [diff] [review]
aurora-specific patch (only includes MAX_AGE changes, not changes to the generated file)

Aurora+
Attachment #8449660 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.