<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Ryan,</p>
<p>Sorry I didn't have time to address this earlier.</p>
<p>Some observations on the points below. Under the old definitions,
over 2020, there were 3024 vulnerabilities [*] disclosed at CVSS
2.0 level 7.0 or higher; under CVSS 3.0, there would be 7385 High
Level or Critical levels to address (ie, >= 7.0). This
represents a significant increase in the number of vulnerabilities
which would need to be patched in the 96 hour window.</p>
<p>Now - I know that not all of those vulnerabilities would actually
be present in many CA systems, but it's reasonable to conclude
that maintaining the 7.0 threshold for CVSS 3.0 would probably
double the patching workload on CAs. That is not necessarily a Bad
Thing: but it is something which CAs would need to consider in
adopting/rejecting this ballot.</p>
<p>In order to keep the number of vulnerabilities (more or less) the
same, the equivalent CVSS v3.0 threshold would be 8.8: in 2020,
there were 3065 such vulnerabilities disclosed. Perhaps that would
be the appropriate level to set the trigger for 96 hour patching?
Agreed, it's diverging from what the CVSS 3.0 ranking calls
"Critical", but should that be a significant concern? At least it
would cover everything which is considered "Critical" by the rest
of the world, and also includes a lot of "this is very, very
serious" issues.<br>
</p>
<p>Of course, to make the thresholding neutral we could adjust it to
be CVSS 2.0 >= 7.0; my concern is that there are several CVSS
3.0 vulnerabilities which are rated critical (>= 9.0) which
have a CVSS 2.0 of < 7.0. In other words, we would allow what
the world considers a "patch now" scenario to be a "patch within 6
months" one. It's not a step _backwards_, but it does seem like a
missed opportunity to step forwards.<br>
</p>
<p>At the very least - can we agree that changing the URL to point
to the correct definitions is uncontroversial?</p>
<p>From a structural standpoint: I agree wholeheartedly that a
markedly improved remediation strategy, aligning with high quality
threat modelling, is what we should be aiming for (and it's why
NetSec has a threat modelling thread in its deliberations). That
will need to form the bases of future ballots.</p>
<p>Just some thoughts,</p>
<p>Neil</p>
<p>[*] My capture of the NVD was done a week or so ago - so it'll be
a bit out of date.<br>
</p>
<div class="moz-cite-prefix">On 15/12/2020 16:53, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWva3TOxbxsC6ov_of8+mS_5w3pffwEk3c_ThNkxgZzOgxQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Neil,</div>
<div><br>
</div>
<div>Just capturing on the list some of the discussion.</div>
<div><br>
</div>
<div>One of the significant changes here is this meaningfully
reduces the security of the ecosystem, by moving the window in
which CAs need to patch from CVSS scores of 7.0 to the much
more rarer 9.0. During the call, it was highlighted that CVSS
1.0 only had three levels (Low, Medium, and High), with the
CA/B Forum determining that any thing at High or above (7.0+)
was, in fact, Critical for CA systems. This new ballot reduces
security, although perhaps unintentionally, by determining
that the only Critical bugs to CA systems are those that CVSS
3.0, which has four levels (Low, Medium, High, Critical),
deems as critical; that is, 9.0+</div>
<div><br>
</div>
<div>As discussed, and obviously captured above, this seems like
a step backwards for security, and there did not seem to be a
compelling reason to allow CAs an additional 6+ months of
patch time simply to align the terminology. For example, this
ballot could redefine "Critical Vulnerability" to "High-Risk
Vulnerability", in order to align terminology. Alternatively,
we could continue with acknowledging that Critical
Vulnerabilities are, due to CAs special nature, anything that
is High or above.</div>
<div><br>
</div>
<div>There was some suggestion that 96 hours is too short a
window to address these events, but we also discussed how, for
better or worse, the NCSSRs afford significant,
non-transparent leeway to CAs to ignore such patch
requirements, by simply requiring CAs either "Create and
implement a plan to mitigate the Critical Vulnerability"
(giving no such timeline to remediation - 4.f.ii) or "Document
that the factual basis for the CA's determination that the
vulnerability does not require remediation" (with the only
requirement being documentation, and no consideration
whatsoever if the factual basis was wrong or the CA's
determination was incorrect - 4.f.iii).</div>
<div><br>
</div>
<div>These are such significant "get out of responsibility free"
cards that it does not seem to justify increasing the barrier
to patching. Recall that, in the absence of something being
deemed a Critical Vulnerability, CAs are afforded six months
to either patch, or determine that they don't want to patch
(1.l).</div>
<div><br>
</div>
<div>Thus, it seems the definition is perhaps the least
important of the things to change, given the structural
security issues with the NCSSRs of the lack of transparency
and accountability required of CAs in keeping their systems
secure. However, if it's urgent to correct this editorial
issue, rather than the underlying security issues, it seems
best to ensure this change is merely editorial in nature, by
continuing to define those events that are critical --for
CAs-- as those that are 7.0 or higher. We know that CVSS
scores provide a baseline metric, but that specific
environments and use cases can either mitigate (as the NCSSRs
seem to give significant deference to) or amplify (as we know
from CA incidents in the past) those scores. As such, it
doesn't seem necessary or desirable to further relax
requirements on CAs' need to maintain a secure-by-default
posture.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 5:44
AM Neil Dunbar via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true">servercert-wg@cabforum.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">This begins the
discussion period for Ballot SC39: Definition of <br>
Critical Vulnerability<br>
<br>
<br>
The following motion has been proposed by Neil Dunbar of
TrustCor and <br>
endorsed by Ben Wilson (Mozilla) and Corey Bonnel
(DigiCert).<br>
<br>
The NetSec discussion document for this ballot is attached
to this email.<br>
<br>
Purpose of Ballot:<br>
<br>
It was brought to the attention of the NetSec Subgroup that
the URL in <br>
the NCSSRs which points to the definitions of the CVSS
security scoring <br>
system is no longer the appropriate one; moreover the
definition of <br>
“Critical Vulnerability” is no longer strictly correct by
the <br>
definitions currently posted by NIST.<br>
<br>
Definitions of terms should always be consistent, especially
when the <br>
term is canonically defined by an external body; references
should be <br>
updated as and when they change on the canonical source.<br>
<br>
-- MOTION BEGINS --<br>
<br>
This ballot modifies the “Network and Certificate System
Security <br>
Requirements” based on Version 1.5.<br>
<br>
Under the section “Definitions”:<br>
<br>
Remove the current definition:<br>
<br>
Critical Vulnerability: A system vulnerability that has a
CVSS score of <br>
7.0 or higher according to the NVD or an equivalent to such
CVSS rating <br>
(see <a href="http://nvd.nist.gov/home.cfm"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://nvd.nist.gov/home.cfm</a>),
or as otherwise designated as a <br>
Critical Vulnerability by the CA or the CA/Browser Forum.<br>
Insert a new definition:<br>
<br>
Critical Vulnerability: A system vulnerability that has a
CVSS v3.0 <br>
score of 9.0 or higher according to the NVD or an equivalent
to such <br>
CVSS rating (see <a
href="https://nvd.nist.gov/vuln-metrics/cvss"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://nvd.nist.gov/vuln-metrics/cvss</a>),
or as <br>
otherwise designated as a Critical Vulnerability by the CA
or the <br>
CA/Browser Forum.<br>
<br>
-- MOTION ENDS --<br>
<br>
* WARNING *: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT
THE OFFICIAL <br>
VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):<br>
<br>
A comparison of the changes can be found at:<br>
<br>
<a
href="https://github.com/cabforum/servercert/compare/8f63128...neildunbar:54c201f"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/cabforum/servercert/compare/8f63128...neildunbar:54c201f</a><br>
<br>
This ballot proposes one Final Maintenance Guideline.<br>
<br>
The procedure for approval of this ballot is as follows:<br>
<br>
Discussion: (7+ days)<br>
Start Time: 2020-12-09 17:00 UTC<br>
End Time: not before 2020-12-16 17:00 UTC<br>
<br>
Vote for approval (7 days)<br>
Start Time: TBD<br>
End Time: TBD<br>
<br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank"
moz-do-not-send="true">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>