Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

An alternate perspective on Symantec

352 views
Skip to first unread message

Peter Kurrasch

unread,
Jun 6, 2017, 3:10:32 PM6/6/17
to MozPol
Over the past months there has been much consternation over Symantec and the idea of "too big to fail". That is a reasonable idea but makes difficult the discussion of remedies for Symantec's past behavior: How does one impose a meaningful sanction without causing Symantec to fail outright since the impact would be catastrophic?

I'd like to offer an alternate perspective on the situation in the hope that it might simplify the discussions of sanctions. The central point is this: Symantec is too big and too complicated to function properly.

Consider:

* Symantec has demonstrated an inability to exercise sufficient oversight and control over the totality of their PKI systems. Undoubtedly there are parts which have been and continue to be well-run, but there are parts for which management has been unacceptably poor.

* No cases have been identified of a breach or other compromise of Symantec's PKI technology/infrastructure, nor of the infrastructure of a subordinate PKI organization for which Symantec is responsible. The possibility does exist, however, that compromises have occurred but might never be known because of management lapses.

* Many of Symantec's customers play a critical role in the global economy and rely on the so-called "ubiquitous roots" to provide their services. Any disruption in those services can have global impacts. Symantec, therefore, plays a significant role in the global economy but only insofar as it is the gatekeeper to the "ubiquitous roots" upon which the global economy relies.

* ‎Symantec has demonstrated admirable commitment to its customers but appear less so when it comes to the policies, recommendations, and openness of the global PKI community. Whether this indicates a willful disregard for the community‎ or difficulty in incorporating these viewpoints into a large organization (or something else?) is unclear.


From this standpoint, the focus of sanctions would be on Symantec's size. Obviously Mozilla is in no position to mandate the breakup of a company but Mozilla (and others) can mandate a reduced role as gatekeeper to the "ubiquitous roots". In fact, Symantec has already agreed to do just that.

In addition, this viewpoint would discourage increasing Symantec's size or adding to the complexity of their operations. I question Symantec's ability to do either one successfully. Symantec is certainly welcome to become bigger and more complex if that's what they should choose, but not as a result of some external mandate.


Comments and corrections are welcome.



David E. Ross

unread,
Jun 6, 2017, 5:21:54 PM6/6/17
to mozilla-dev-s...@lists.mozilla.org
I was going to suggest that indeed Symantec be put out of business by
refusing to add any new roots to NSS and refusing to update any expiring
roots. However, that would be a weak response since only one root
expires in the current decade, in a little less than two years from now.
Many of the Symantec-branded roots do not expire until 6-8 years from
now. Most of Symantec's Verisign-branded roots will not expire in my
lifetime (and my family has extraordinary longevity).

I would suggest that Symantec be placed on a form of probation. The
terms of probation would be that any further negligence or other
unacceptable operations within the next nn [some small number] years
would cause all Symantec controlled roots to be promptly deprecated
(e.g., removed from NSS, left in NSS but marked invalid). The terms of
probation would specify clear, detailed, objective meanings of
negligence and other unacceptable operations sufficient to withstand
legal challenges if deprecation is indeed imposed.

A notice of this probation must be made broadly public. Before public
release, however, hard copies of the notice should sent by postal mail
both to the CEO of Symantec and to the top management of Symantec's
outside auditors, signed by both Mitchell Baker and Chris Beard. That
mailed notice should direct Symantec to notify promptly all holders of
subscriber certificates of the terms of the probation. This would warn
potential users of concern over Symantec's operations. This would also
give existing users time to consider renewing their expiring subscriber
certificates with other certification authorities. The end result would
shrink Symantec.

--
David E. Ross
<http://www.rossde.com>

Consider:
* Most state mandate that drivers have liability insurance.
* Employers are mandated to have worker's compensation insurance.
* If you live in a flood zone, flood insurance is mandatory.
* If your home has a mortgage, fire insurance is mandatory.

Why then is mandatory health insurance so bad??

userwithuid

unread,
Jun 7, 2017, 1:14:50 AM6/7/17
to mozilla-dev-s...@lists.mozilla.org
Inspired by David's message, 2 suggestions for the Symantec plan:

1. Mozilla - and ideally Google as well - should clearly and explicitly communicate in the official statement on this that the "new" Symantec will still be strictly monitored even after the current remediation plan has been implemented. Their issue history still very much counts, potentially resulting in much harsher responses to future policy violations than would be the case for first-time offenders/other CAs. This is to counter the potential misconception (aka marketing) that everything is totally fine now.

2. Having Symantec inform their subscribers, as David mentions, is a great idea. Specifically, I think Symantec should be required to make their subscribers aware of the Mozilla-written! statement regarding the future of their CA, soon (<=1 month?) after its release. This is to prevent too many subscribers from getting caught by surprise in the future (see StartCom), to give them a chance to see more than one side, CA view _and_ Mozilla view, and to ensure they know they are Symantec subscribers in the first place (RapidSSL cert chaining to a GeoTrust root bought from some reseller = Symantec? yeah, totally obvious...).

Gervase Markham

unread,
Jun 8, 2017, 5:07:44 AM6/8/17
to userwithuid
On 07/06/17 06:14, userwithuid wrote:
> 2. Having Symantec inform their subscribers, as David mentions, is a great idea.

I believe Ryan has pointed out, here or elsewhere, why "must notify
customers" requirements are problematic.

Gerv


Peter Kurrasch

unread,
Jun 8, 2017, 8:55:12 AM6/8/17
to mozilla-dev-security-policy
Let's also consider some of the companies that use the ubiquitous roots: Coca Cola, Pepsico, Nike, the CIA, all major US banks, and probably most major US companies and consumer brands. Consider, too, that in addition to their regular business they have many marketing sites and various other consumer engagement portals--and, oftentimes, these microsites will be developed and operated by a outside firm.

So in cases like these companies and brands, the notification can get complicated and possibly counter-productive. If I'm the outside firm ‎handling a special portal for some "super spicy cheesy puffs" marketing campaign (a hypothetical example), I might not care about Symantec or even website security because my livelihood depends on getting the portal up in time to launch the campaign at the next major sporting event. Assuming the portal even uses a certificate, the choice of CA to issue it might not even be mine to make. (And if the site should stop working for Firefox users because of an action taken against Symantec, you can bet it will make many people very angry.)

I'm all for notifications and raising awareness but it's not necessarily easy or straight-forward to get the right message to the decision makers and the people who have to execute those decisions.


From: Gervase Markham via dev-security-policy
Sent: Thursday, June 8, 2017 4:07 AM
Reply To: Gervase Markham
Subject: Re: An alternate perspective on Symantec

On 07/06/17 06:14, userwithuid wrote:
> 2. Having Symantec inform their subscribers, as David mentions, is a great idea.

I believe Ryan has pointed out, here or elsewhere, why "must notify
customers" requirements are problematic.

Gerv


_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

0 new messages