1012875 - Reduce pinset lifetime to 8 weeks once it reaches stable

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[[:mmc] Monica Chew (no longer reading bugmail)]

Chrome's is at 10 weeks, and they asked us to reduce ours.

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.

Comment 2

[[:mmc] Monica Chew (no longer reading bugmail)]

Once bug 1004279 is resolved, then it will be x weeks from the release build date. I think that's the correct starting time.

Comment 3

[Camilo Viecco (:cviecco)]

(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?

Comment 4

[[:mmc] Monica Chew (no longer reading bugmail)]

(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.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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.

Comment 6

[[:mmc] Monica Chew (no longer reading bugmail)]

> 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?

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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.

Comment 8

[[:mmc] Monica Chew (no longer reading bugmail)]

> 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.

Comment 9

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: expire

Comment 10

[Camilo Viecco (: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.

Comment 11

[[:mmc] Monica Chew (no longer reading bugmail)]

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.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Comment on attachment 8432818 [details] [diff] [review]
expire

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

Good to go.

Comment 13

[[:mmc] Monica Chew (no longer reading bugmail)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c93e297aaaf1

Comment 14

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: aurora-specific patch (only includes MAX_AGE changes, not changes to the generated file)

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.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c93e297aaaf1

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8449660 [details] [diff] [review]
aurora-specific patch (only includes MAX_AGE changes, not changes to the generated file)

Aurora+

Comment 17

[[:mmc] Monica Chew (no longer reading bugmail)]

Thanks!

https://hg.mozilla.org/releases/mozilla-aurora/rev/2a985fb59e4b