Re: Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

On 28/07/17 07:14, Gervase Markham wrote:
> I would like to make a decision on this matter on or before July 31st,

After listening to the opinions here on m.d.s.p., and consultation
within Mozilla and with our engineering teams, on the matter of when to
distrust various bits of the existing Symantec PKI we have decided to
match the dates proposed by Google for Chrome (within a few weeks; exact
Firefox releases will be determined nearer the time).

This is not the outcome we would have preferred (clearly, as it doesn't
match our earlier proposal) but, given the choice before us, the
benefits of a consistent cross-browser approach have been judged to be
greater than the benefits of Mozilla unilaterally setting an earlier date.

We expect these dates to be hit; we would look dimly on any last-minute
requests to move them. I would also reiterate, in case it becomes
relevant, that any change of control of some or all of Symantec's roots
would not be grounds for a renegotiation of these dates.

We hope that we can now move swiftly to the implementation phase, and
that as it progresses we will see improved levels of security for web
users and improved confidence in the WebPKI. We will be expecting and
looking for exemplary standards of CA best practice from Symantec in
general, and their new PKI in particular, going forward.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

On 31/07/17 15:17, Jakob Bohm wrote:
> I am referring to the fact that EV-trust is currently assigned to roots,
> not to SubCAs, at least as far as visible root store descriptions go.

You said the problem was Mozilla-specific; do other root stores not do
it this way?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[userwithuid via dev-security-policy]

WRT to the deadlines: If the decision is to sync up, I think it's worth noting 
that Firefox probably needs to release 2-3 weeks after a Chrome "release date" 
to achieve this in practice.

Why? Firefox updates take ~10days from release date to reach previous version 
numbers. Chrome _can_ do it in the same time, but sometimes they slow update 
propagation considerably - and the distrust events could very well be reasons 
to do this.

Take for example Chrome 57: Release date for desktop was March 9 [1], but 
propagation was throttled heavily for the first ~20 days, resulting in a total 
of ~30 days. [2] Chrome 57 for Android, supposedly released March 16 - always a 
week later than desktop! - was also held back for most? users for ~3-4 weeks 
iirc (can't find a graph right now, sorry).

So unless Mozilla is eager to deal with most of the immediate outfall of the 
trust changes on its own (at which point we might as well set stricter 
deadlines), it should strategically fall behind.

Dates in question:
* Firefox 60 on 2018-05-01 for old PKI notBefore >=2016-06 -> already close, 
only 2 weeks after
* Firefox 64 on 2018-11-27 for the full distrust -> 5 weeks after. Bonus: All 
the 1-year certs from the old PKI will have expired as well.

[1] 
https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html
[2] 
http://gs.statcounter.com/browser-version-market-share/desktop/worldwide/#daily-20170301-20170501





On Monday, July 31, 2017 at 2:01:57 PM UTC, Gervase Markham wrote:
> On 29/07/17 23:45, Peter Bowen wrote:
> > First, when the server authentication trust will bits be removed from
> > the existing roots.  This is of notable importance for non-Firefox
> > users of NSS.  Based on the Chrome email, it looks like they will
> > remove trust bits in their git repo around August 23, 2018.  When will
> > NSS remove the trust bits?
> 
> The NSS trust store represents Mozilla's decisions about what is
> trustworthy. However, particularly if we match Chrome's dates, there is
> a slightly unusual situation as we have taken a decision on
> trustworthiness but, for other reasons, Firefox still trusts those certs
> for a period. So one might well ask, should the decision be implemented
> in NSS earlier than, or at the same time as, or even later than, Firefox
> implements it? A good question.

If you enjoy making things harder for other people you can go with earlier :-P 
. Seriously though, that would only make sense from a Mozilla release process 
perspective but is totally unexpected and annoying for any other NSS consumer - 
they will just have to postpone that NSS update or restore the roots 
temporarily.

I think it makes most sense to land Firefox internal distrust shortly before 
branching, like Chrome, use beta for gauging impact, release, then ~2 weeks 
after release date do a NSS point release with only the certdata changes for 
other consumers and future Firefox versions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Eric Mill via dev-security-policy]

Given that we're past the 7/31 deadline and the comments in support of
following Chrome's lead, it sounds likely that that's what's happening. And
I think that's an understandable conclusion for Mozilla to draw, given the
compatibility risk Mozilla would be leading on for at least several months.

However, I think Mozilla should consider the larger precedent being set by
Mozilla deferring to such a significant relaxation in enforcement by Chrome
in such a complete way.

It's quite possible that Chrome's original proposed timetable was too
aggressive, but their final proposed timetable is quite weak, and it seems
like participants here generally agree that a partial distrust date in
December, preceding the holiday season, would be a reasonable conclusion.

I find it particularly disheartening that Symantec has been able to
successfully deploy hardball tactics to obtain more favorable treatment
from Google, and now likely Mozilla. As has been discussed amply on this
list, Symantec engaged the bare minimum necessary with the Mozilla
community, repeatedly missed or just made deadlines, and refused to answer
follow-up questions from community participants.

On at least one occasion, Symantec publicly pressured Mozilla to halt
public discussion about independent enforcement in favor of waiting for
Google's decision, from what appeared to be barely contained glee from
managing to get Google executives involved to slow down the process and
obtain a weaker proposal.

I also want to point out that Symantec's customer communication from around
July 11th, as shared on blink-dev:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/
eUAKwjihhBs/smcHvd2HAgAJ

Instructs their customers to replace all of their certificates issued
before June 2016 by August 8th:


One aspect of Google’s proposal is that starting August 8, 2017, Chrome
would gradually begin mistrusting all Symantec branded certificates issued
before June 1, 2016.

We urge you take prompt action in order to avoid the risk of having your
certificates mistrusted by Google’s Chrome browser. At the end of this
email is an instruction to identify your certificates that are at risk, and
the date which Google has stated they may begin mistrusting them.

We recommend that you replace these certificates prior to August 8, 2017 to
minimize any disruption.


Symantec is referencing dates from a previous Chrome proposal by Ryan
Sleevi:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/
eUAKwjihhBs/ovLalSBRBQAJ

But Chrome's proposal only references August 8th as the date Symantec
should be issuing all certificates from their managed PKI. The proposal
said that existing certs issued before June 2015 would be distrusted on
August 31st, and existing certs issued before June 2016 would be issued in
January 2018.

The net effect of Symantec's customer communication is that Symantec sent
its customers into a low-grade panic by waiting for almost 2 months from
the May proposal date to send them an email that, for most customers,
certainly appears to suggest that in 3 weeks, all their pre-June-2016 certs
will start causing errors.

The Symantec references a list of specific dates per-cert, which presumably
match Chrome's specific proposal, but I can tell you that I have observed
Symantec customers interpret this communication as an impending August 8th
distrust date for existing Symantec certificates in Chrome.

I find it quite plausible that Symantec deliberately encouraged unnecessary
anxiety among their customer base by delaying this notice and overstating
the severity of the distrust event, to validate their arguments about risk
to internet service availability and to strengthen their negotiating
position with Google.

But even if their intent was not quite so bad-faith, Symantec's handling of
this process was at the very least highly disorganized and belligerent, to
the point that I think Mozilla would be within their rights to lose
confidence in Symantec's future participation in the Mozilla root program.

So whatever Mozilla chooses to do, I hope that it reflects Mozilla's
independent assessment of the risk posed to their users by Symantec's
current certificate corpus and their expected participation in the program,
and that it reinforces Mozilla as an independent party in future
negotiations with other members of their root program.

-- Eric

On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; 

Re: Final Decision by Google on Symantec

[Peter Bowen via dev-security-policy]

On Mon, Jul 31, 2017 at 7:17 AM, Jakob Bohm via dev-security-policy
 wrote:
> On 31/07/2017 16:06, Gervase Markham wrote:
>>
>> On 31/07/17 15:00, Jakob Bohm wrote:
>>>
>>> - Due to current Mozilla implementation bugs,
>>
>>
>> Reference, please?
>>
>
> I am referring to the fact that EV-trust is currently assigned to roots,
> not to SubCAs, at least as far as visible root store descriptions go.
>
> Since I know of no standard way for a SubCA certificate to state if it
> intended for EV certs or not, that would cause EV-trust to percolate
> into SubCAs that were never intended for this purpose by the root CA.

This is common to every EV implementation I know about, not just
Mozilla.  Therefore I would not call this a bug.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Jakob Bohm via dev-security-policy]

On 31/07/2017 16:06, Gervase Markham wrote:

On 31/07/17 15:00, Jakob Bohm wrote:

It was previously stated in this newsgroup that non-SSLServer trust
would not be terminated, at least for now.


It was? Reference, please?



That was my general impression, I don't have a good way to search the
list for this.  I was just trying to be helpful.


- Due to current Mozilla implementation bugs,


Reference, please?



I am referring to the fact that EV-trust is currently assigned to roots,
not to SubCAs, at least as far as visible root store descriptions go.

Since I know of no standard way for a SubCA certificate to state if it
intended for EV certs or not, that would cause EV-trust to percolate
into SubCAs that were never intended for this purpose by the root CA.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

On 29/07/17 23:45, Peter Bowen wrote:
> First, when the server authentication trust will bits be removed from
> the existing roots.  This is of notable importance for non-Firefox
> users of NSS.  Based on the Chrome email, it looks like they will
> remove trust bits in their git repo around August 23, 2018.  When will
> NSS remove the trust bits?

The NSS trust store represents Mozilla's decisions about what is
trustworthy. However, particularly if we match Chrome's dates, there is
a slightly unusual situation as we have taken a decision on
trustworthiness but, for other reasons, Firefox still trusts those certs
for a period. So one might well ask, should the decision be implemented
in NSS earlier than, or at the same time as, or even later than, Firefox
implements it? A good question.

> Second, how the dates apply to email protection certificates, if at
> all.  Chrome only deals with server authentication certificates, so
> their decision does not cover other types of certificates.  Will the
> email protection trust bits be turned off at some point?

Absent the bandwidth to spend more time on email-specific issues with
our root store, I would expect to stop trusting all the same roots for
email as well, at the same time.

> Third, what the requirements are for Symantec to submit new roots,
> including any limit to how many may be submitted.
> https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
> shows that there are currently 20 Symantec roots included.  Would it
> be reasonable for them to submit replacements on a 1:1 basis -- that
> is 20 new roots?

No. A new submission would be treated as any new submission. My guess
without talking to Symantec was that they might want four roots, for a
2x2 matrix of {RSA, ECC} and {EV, non-EV}. A figure in that ballpark
would be acceptable.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Jakob Bohm via dev-security-policy]

On 30/07/2017 00:45, Peter Bowen wrote:

On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via
dev-security-policy  wrote:

Google have made a final decision on the various dates they plan to
implement as part of the consensus plan in the Symantec matter. The
message from blink-dev is included below.


[...]


We now have two choices. We can accept the Google date for ourselves, or
we can decide to implement something earlier. Implementing something
earlier would involve us leading on compatibility risk, and so would
need to get wider sign-off from within Mozilla, but nevertheless I would
like to get the opinions of the m.d.s.p community.

I would like to make a decision on this matter on or before July 31st,
as Symantec have asked for dates to be nailed down by then in order for
them to be on track with their Managed CA implementation timetable. If
no alternative decision is taken and communicated here and to Symantec,
the default will be that we will accept Google's final proposal as a
consensus date.


Gerv,

I think there three more things that Mozilla needs to decide.

First, when the server authentication trust will bits be removed from
the existing roots.  This is of notable importance for non-Firefox
users of NSS.  Based on the Chrome email, it looks like they will
remove trust bits in their git repo around August 23, 2018.  When will
NSS remove the trust bits?

Second, how the dates apply to email protection certificates, if at
all.  Chrome only deals with server authentication certificates, so
their decision does not cover other types of certificates.  Will the
email protection trust bits be turned off at some point?



It was previously stated in this newsgroup that non-SSLServer trust
would not be terminated, at least for now.


Third, what the requirements are for Symantec to submit new roots,
including any limit to how many may be submitted.
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
shows that there are currently 20 Symantec roots included.  Would it
be reasonable for them to submit replacements on a 1:1 basis -- that
is 20 new roots?



Those 20 old roots were the result of decades of mergers and
acquisitions, causing lots of "duplicates".

That said, it is better for overall security to have meaningful splits
of root CAs for any new CAs.  Most notably:

- Issuing a new (cross-signed) root for each new signature algorithm.  A
 full service CA should currently have roots for RSA-SHA256, RSA-SHA384,
 RSA-SHA512, and the ECDSA curves above 256 bits, each paired with the
 matching SHA size.  Others would be added 6 to 24 months after becoming
 BR-permitted.

- Due to current Mozilla implementation bugs, having separate roots for
 EV certificates is currently the only way to only accept EV certs from
 EV SubCAs.  This is specific to Mozilla.

- If Symantec wants to again set up a trust tree dedicated to cross-
 signing lots of outside parties (similar to the old "GeoRoot" program),
 it would be best to put that under separate roots.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Jakob Bohm via dev-security-policy]

On 28/07/2017 18:36, David E. Ross wrote:

On 7/28/2017 6:34 AM, Alex Gaynor wrote:

Frankly I was surprised to see Chromium reverse course on this -- they have
a history of aggressive leadership in their handling of CA failures, it's a
little disappointing to see them abandon that.

I'd strongly advocate for us perusing an earlier date -- December 1st at
the latest. Reasons:

1) Chromium's stated reason for avoiding dates around the holidays makes no
sense -- organizations with change freezes they need to adhere to have a
simple solution: obtain and deploy a new certificate at an earlier date!
They have 4 months between now and December 1st, if you can't deploy a cert
in 4 months, I submit you have larger problems.

2) It is important that CAs not be rewarded for the length of time this
process takes. CAs should be encouraged and rewarded for active
participation and engagement in this list.

3) Mandatory CT (well, mandatory for trust in Chromium) is a significant
win for security and transparency. At the moment, even discussing the
parameters of the distrust is complicated by the fact that we have limited
visibility into the iceberg of their PKI before June 1st, 2016 (see the
other thread where I attempt to discuss the count they provide of
outstanding certs that would be impacted). Given the challenges we know
exist in their legacy PKI, I think it's fair to say that continuing to
trust these certs represents real risk for our users's security.

Alex


I strongly agree.  The focus must be on protecting end-users, not on
Symantec or on Symantec's customers.

Symantec must know who has subscriber certificates that chain to
Symantec's roots.  Those customers could all be notified very quickly
that their certificates are about to be distrusted.  Those customers
would then have ample time to obtain and install replacement subscriber
certificates chaining to alternative roots of other certification
authorities.

As for any disruption of secure transactions, consider the abrupt
termination of DigiNotar when that certification authority was found to
have serious lapses in its operations.  The world did not end.



Note that DigiNotar was a country-local CA, not a global CA.  The risk
profile (for distrust, not for mis-issuance) was much lower.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Peter Bowen via dev-security-policy]

On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via
dev-security-policy  wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
[...]
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.

Gerv,

I think there three more things that Mozilla needs to decide.

First, when the server authentication trust will bits be removed from
the existing roots.  This is of notable importance for non-Firefox
users of NSS.  Based on the Chrome email, it looks like they will
remove trust bits in their git repo around August 23, 2018.  When will
NSS remove the trust bits?

Second, how the dates apply to email protection certificates, if at
all.  Chrome only deals with server authentication certificates, so
their decision does not cover other types of certificates.  Will the
email protection trust bits be turned off at some point?

Third, what the requirements are for Symantec to submit new roots,
including any limit to how many may be submitted.
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
shows that there are currently 20 Symantec roots included.  Would it
be reasonable for them to submit replacements on a 1:1 basis -- that
is 20 new roots?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Nick Lamb via dev-security-policy]

Other contributors have, I think, summed up the pros and cons of the two ways 
forward on the specific date very effectively.

So I will expend my effort instead on pressing for Mozilla to handle final 
distrust of the old Symantec CA roots in its usual fashion and explicitly _not_ 
do as Symantec asked in leaving it enabled in the NSS trust set we know is 
relied upon (whether wisely or not) by lots of things other than web browsers.

Once we have firm dates, I also recommend that we look for opportunities to 
advertise this issue and key deadline(s) to outfits like Qualys who are 
scanning web sites etc and reporting what they find. Regardless of any contact 
from Symantec, there still is no substitute for independent voices saying "This 
is a real problem, you need to take action by Specific Date or bad things will 
happen". Larger corporations will already have a process in place to assess the 
output of such scans, organise them by urgency and priority and get stuff done, 
which is what we need here, but they buy scans perhaps only once per year, so 
we need this to show up sooner rather than later to maximise the chance of 
resolution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[J.C. Jones via dev-security-policy]

I share the desire to move faster than these dates, but upon
consideration, I don't think it's much of a boon to web security for
Mozilla to be substantially ahead of Chrome in implementing these trust
changes.

Since Chrome's decision to implement in April is final, their large user
population is exposed to any problem certificates until then; presumably
they believe the risk is low enough to proceed that way. No matter what
choice we make, the Web PKI as a whole has this nebulous danger until
Chrome's implementation date arrives.

If Firefox chooses to move faster, we'd need to educate users on why
some websites are functioning in Chrome but not in Firefox, for over 5
months. While we all know users need more education on security on the
Web, I don't want to spend their attention spans on this particular issue.

I think we should match Google's 17 April date.

(For the record: I am not swayed by this talk in July about avoiding Q4
configuration freezes; I absolutely agree with 1 December 2017 being a
practical cut-off date as long as the decision point is in the next
several days.)

J.C.


On 7/27/17 11:14 PM, Gervase Markham via dev-security-policy wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:  Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date: Thu, 27 Jul 2017 17:16:06 -0700
> From: Darin Fisher 
> To:   Darin Fisher 
> CC:   blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
> ,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered a number of alternative dates for distrusting this subset
> of existing certificates before landing on Chrome 66. Given the scale of
> Symantec’s existing PKI and the impact to the ecosystem that these
> mitigations pose, one of our goals was to consider dates that gave site
> operators enough lead time, as well as to try to clear 

Re: Final Decision by Google on Symantec

[Jonathan Rudenberg via dev-security-policy]

> On Jul 28, 2017, at 09:34, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Frankly I was surprised to see Chromium reverse course on this -- they have
> a history of aggressive leadership in their handling of CA failures, it's a
> little disappointing to see them abandon that.
> 
> I'd strongly advocate for us perusing an earlier date -- December 1st at
> the latest.

I strongly agree. Even if an organization has a conservative freeze in October 
for Black Friday/Cyber Monday at the end of November, replacing certificates 
issued before 2016-06-01 within the next two months should be feasible. If 
re-issuing these old certificates is problematic in any way, I would have 
expected Symantec to warn their customers and provide a solution immediately in 
March after Chrome released the first version of their plan for distrust based 
on validity period or in April/May when Chrome’s subsequent revisions of the 
plan included the 2017-08-08 distrust date.

Actions are much more compelling than delay tactics and counter-proposals, so 
the complete lack of proactive measures from Symantec indicates to me that they 
do not consider the implementation of the various detailed proposals of 
distrust over the next few months to be a problem for their customers.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[okaphone.elektronika--- via dev-security-policy]

On Friday, 28 July 2017 08:15:43 UTC+2, Gervase Markham  wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
> 
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
> 
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
> 
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
> 
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
> 
> Gerv

I can understand that it would be safest (from the point of PR) to remove their 
roots more or less at the same time as Chrome. But the simple fact that 
Symantec is still playing "to big to fail" shows that THEY will not do what is 
in the interest of the browser users... Browsers and browser users will 
therefore have to fend for themselves. I'd say allowing them until november 1st 
is a very generous implementation of "some time in 2018" and will have to do 
for them. After all they have been dragging their feet for months now. They 
could actually have used all that wasted time... ;-)

CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[David E. Ross via dev-security-policy]

On 7/28/2017 6:34 AM, Alex Gaynor wrote:
> Frankly I was surprised to see Chromium reverse course on this -- they have
> a history of aggressive leadership in their handling of CA failures, it's a
> little disappointing to see them abandon that.
> 
> I'd strongly advocate for us perusing an earlier date -- December 1st at
> the latest. Reasons:
> 
> 1) Chromium's stated reason for avoiding dates around the holidays makes no
> sense -- organizations with change freezes they need to adhere to have a
> simple solution: obtain and deploy a new certificate at an earlier date!
> They have 4 months between now and December 1st, if you can't deploy a cert
> in 4 months, I submit you have larger problems.
> 
> 2) It is important that CAs not be rewarded for the length of time this
> process takes. CAs should be encouraged and rewarded for active
> participation and engagement in this list.
> 
> 3) Mandatory CT (well, mandatory for trust in Chromium) is a significant
> win for security and transparency. At the moment, even discussing the
> parameters of the distrust is complicated by the fact that we have limited
> visibility into the iceberg of their PKI before June 1st, 2016 (see the
> other thread where I attempt to discuss the count they provide of
> outstanding certs that would be impacted). Given the challenges we know
> exist in their legacy PKI, I think it's fair to say that continuing to
> trust these certs represents real risk for our users's security.
> 
> Alex

I strongly agree.  The focus must be on protecting end-users, not on
Symantec or on Symantec's customers.

Symantec must know who has subscriber certificates that chain to
Symantec's roots.  Those customers could all be notified very quickly
that their certificates are about to be distrusted.  Those customers
would then have ample time to obtain and install replacement subscriber
certificates chaining to alternative roots of other certification
authorities.

As for any disruption of secure transactions, consider the abrupt
termination of DigiNotar when that certification authority was found to
have serious lapses in its operations.  The world did not end.

-- 

David E. Ross
.

The only reason we have so many laws is that not enough people will do
the right thing.  (© 1997 by David Ross)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Vincent Lynch via dev-security-policy]

Hi Gerv,

Thank you for reaching out to the mdsp community.

There are valid security reasons to consider a dis-trust date earlier than
April 2018 for the corpus of Symantec certs issued prior to June 1st, 2016.

However, I also believe there are security and operational risks in
complicating the needed remediation by having two major browsers propose
different dis-trust dates.

I believe the internet community would benefit more from simplified
messaging than they would from a dis-trust date that is a few months
earlier. For that reason, I think Mozilla should match Google's April 2018
dis-trust date.

Thank you,

Vincent

[Disclaimer: I work for a company that sells Symantec SSL certificates, but
am commenting in a personal capacity.]

On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date:   Thu, 27 Jul 2017 17:16:06 -0700
> From:   Darin Fisher 
> To: Darin Fisher 
> CC: blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
>  y7IRQALJBgAJ>,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered a number of alternative dates for distrusting this subset
> of existing certificates before landing on Chrome 66. Given the scale of
> Symantec’s existing PKI and the impact to the ecosystem that these
> mitigations pose, one of our goals was to consider dates that gave site
> operators enough lead time, as well as to try to clear end-of-year time
> periods where production freezes are typically in place. Chrome 62 which
> comes out in October 2017 was seriously considered, but was rejected due
> to concerns around not giving enough lead time for site operators.
> Chrome 63 which comes out in December was rejected due to overlapping
> 

Re: Final Decision by Google on Symantec

[Alex Gaynor via dev-security-policy]

Frankly I was surprised to see Chromium reverse course on this -- they have
a history of aggressive leadership in their handling of CA failures, it's a
little disappointing to see them abandon that.

I'd strongly advocate for us perusing an earlier date -- December 1st at
the latest. Reasons:

1) Chromium's stated reason for avoiding dates around the holidays makes no
sense -- organizations with change freezes they need to adhere to have a
simple solution: obtain and deploy a new certificate at an earlier date!
They have 4 months between now and December 1st, if you can't deploy a cert
in 4 months, I submit you have larger problems.

2) It is important that CAs not be rewarded for the length of time this
process takes. CAs should be encouraged and rewarded for active
participation and engagement in this list.

3) Mandatory CT (well, mandatory for trust in Chromium) is a significant
win for security and transparency. At the moment, even discussing the
parameters of the distrust is complicated by the fact that we have limited
visibility into the iceberg of their PKI before June 1st, 2016 (see the
other thread where I attempt to discuss the count they provide of
outstanding certs that would be impacted). Given the challenges we know
exist in their legacy PKI, I think it's fair to say that continuing to
trust these certs represents real risk for our users's security.

Alex


On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date:   Thu, 27 Jul 2017 17:16:06 -0700
> From:   Darin Fisher 
> To: Darin Fisher 
> CC: blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
>  y7IRQALJBgAJ>,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered 

Re: Final Decision by Google on Symantec

[Jakob Bohm via dev-security-policy]

As it stands, aligning with Chrome, plus/minus 14 days would be the best
approach.

It is of cause regrettable that Symantec managed to delay the decision
process until a time when key Mozilla personnel (most notable Gerv)
where unavailable, thus allowing Chrome to make the decisions while
Mozilla was waiting for the summer vacations to end.  But done is done,
and at this point its better to keep the established schedule than a
similar-but-different schedule which would simply confuse matters.

Maybe Mozilla should, as quickly as possible, create a (temporary)
about:config setting "security.certs.symantec.testdate" which can be
used by site operators to test how the planned behavior would affect
their current site over the transition period.  For example, setting
this to "2018-03-15" would make the trust of Symantec WebPKI certs
follow the planned timeline as it would apply to the most recent
released browser available on that particular date.  The setting would
go away when the last deadline passes In late 2018.

Of cause until the managed SubCA certs are known, this would trust an
empty set of such certificates for that role, but that's OK since no end
certs would have been issued from them either.

Also (Mozilla and Chrome) should reach out to Qualsys to encourage them
to incorporate the timetable and related warnings into their ssllabs.com
test service.

Of cause, Symantec itself should use its internal records to reach out
to affected certificate subscribers telling them when each of their
existing certificates would be affected (if at all), which replacement
product Symantec recommends for each one, and if there will be any
pro-rata discount for that replacement.

Something like this:

Example text only e-mail, sent from symantec.com e-mail and digitally
signed with a Symantec-issued S/MIME certificate:
(Return receipt requested from e-mail clients that do that).

> Subject: EMERGENCY Replacement of some of your certificates.
> OR: Your certificates not affected by emergency replacement.
> (latter subject used if the count of affected certificates is 0).
>
> Dear [customer name] <[n...@example.com]>
>
> Due to security issues, it is necessary to replace some Symantec-
> issued certificates before their original expiry dates in order for
> your website to continue to work in various browsers.  Below is a list
> of the certificates you have purchased using this e-mail address as
> one of the official points of contact and how they will be affected.
>
> For background information, please see https://www.symantec.com/xx
> Or go directly to the www.symantec.com front page and click on the
> link marked "early certificate replacements 2017-2018".
>
> www.example.com serial number 123456890123456890123456890123456890
> Issued for: www.example.com, example.com
> Symantec brand: Verisign
> Issued: Jan 15, 2016
> Original expiry: Jan 15, 2018
> NOT AFFECTED
>
> www.example.net serial number 567890123456890123456890123456890120
> Issued for: www.example.net, 192.0.2.1 (IP address)
> Symantec brand: Symantec
> Issued: May 30, 2016
> Original expiry: May 30, 2019
> NEW EXPIRY IN SOME BROWSERS: April 17, 2017
> NEW EXPIRY IN TEST BROWSERS: January 19, 2017
> Suggested replacement: Order a replacement 2 year certificate from
> Symantec between December 2, 2017 and April 17, 2017 with a pro-rata
> discount of ??%.  Or order a replacement 1 year certificate from
> Symantec between December 2, 2017 and April 17, 2017 with a pro-rata
> discount of ??%.
>
> c...@example.com serial number ABCDEFABCDEFABCDEFABCDEFABCDEFABCDEF
> Issued for: c...@example.com (e-mail)
> Symantec brand: Symantec
> Issued: May 20, 2016
> Original expiry: May 20, 2019
> NOT AFFECTED
>
> Total: 3 certificates issued, 1 affected.



On 28/07/2017 08:14, Gervase Markham wrote:

Google have made a final decision on the various dates they plan to
implement as part of the consensus plan in the Symantec matter. The
message from blink-dev is included below.

Most of the dates have consensus - the dates for Symantec to implement
the Managed CA infrastructure are agreed by all, and the date for final
distrust of the old Symantec PKI is agreed by Google and Mozilla (to
within a week, at any rate). I proposed November 1st 2018. Google has
gone for October 23rd 2018; in practical terms, we would implement that
using Firefox 63 (October 16th) or 64 (November 27th).

However, there is some difference in the proposals for the date on which
browsers should dis-trust Symantec certificates issued before June 1st,
2016. This date is significant because after that, Symantec have been
required to log all their certs to CT and so there is much better
transparency of issuance practice. I proposed December 1st 2017. Google
strongly considered late January, but have finally chosen April 17th 2018.

We now have two choices. We can accept the Google date for ourselves, or
we can decide to implement something earlier. Implementing something
earlier would involve us 

Re: Final Decision by Google on Symantec

[wizard--- via dev-security-policy]

With respect to the date of distrust of symantec certificates issues before 
June 1, 2016, I believe Mozilla has a third option:

Remove indicators of trust (green lock, etc.) on December 1, 2017 for Symantec 
certificates issued prior to June 1, 2016 (but do not produce interstitials and 
do not actively distrust until April 17th 2018).

Yes, this is somewhat more engineering work for Mozilla, but it strikes the 
right balance between usability and safety.

Why? The underlying security rationale for an earlier distrust of certificates 
issued prior to June 1, 2016 is that there is no CT disclosure requirement for 
DV/OV. The lack of transparency afforded to issuances prior to June 1, 2016, 
inherently makes them "riskier" to end users given Symantec's demonstrated 
prior practices.

The above strategy properly incorporates that additional risk in the trust 
decision, while not introducing the much larger potential compatibility issues 
of full distrust of old certificates on the same day that the managed CA 
becomes fully operational.

Mozilla could even consider waiving the above if Symantec were to log *all* 
(including expired and revoked) certificates from prior to June 1, 2016 [with 
the enforcement being: if anyone in the world provides Mozilla with a copy of 
even a single certificate that is not in CT after Symantec says that they are, 
then the above, or something more stringent, immediately goes into effect]. 
Symantec has even provided a fairly accurate count of how many non-expired, 
non-revoked certificates prior to June 1, 2016 should be present as an initial 
sanity check.

Note this strategy may also help eliminate compatibility problems April 17th 
2018, since there will have been a large period of time where indicators of 
trust were removed (but otherwise remaining functional).

On Friday, July 28, 2017 at 2:15:43 AM UTC-4, Gervase Markham wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
> 
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
> 
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
> 
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
> 
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
> 
> Gerv
> 
>  Forwarded Message 
> Subject:  Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date: Thu, 27 Jul 2017 17:16:06 -0700
> From: Darin Fisher 
> To:   Darin Fisher 
> CC:   blink-dev 
> 
> 
> 
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
> 
> 
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
> 
> 
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
> 
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
>