CVE ID Syntax Change - MITRE Recommendation

["Steven M. Christey" <coley@mitre.org>]

All,

The MITRE CVE Team met on Monday, February 11 to discuss the CVE ID
syntax change.  We reviewed the final three syntax options in light of
the feedback that we have received so far, along with our own
judgments of the strengths and weaknesses of each option.  We selected
an option that we will recommend to the Board, to be described below.

We will go into RSA with this recommendation in mind, and we will
continue to get public feedback.  We will hold the formal vote with
the Editorial Board soon after the conference.  Then, we will make a
final decision and public announcement at the end of Match.

(tl;dr - we recommend Option A.)


To review, the three options are:

Option A - 6 digits, leading 0's (CVE-2014-000001, CVE-2014-123456)

Option B - arbitrary digits except <999 (CVE-2014-0001, CVE-2014-12345)

Option C - arbitrary digits + check digit (CVE-2014-1-8, CVE-2014-123456-5)


Even with the recent press attention, we have only received about 40
responses to the cve-id-change@mitre address, and there has been some
discussion in mailing lists and social media such as Twitter.  This
suggests that most consumers either (1) don't care or (2) are able to
handle any option we select.  There's also the likelihood that we
haven't reached everybody who has a stake in the syntax change, but we
have made a good effort to notify the public, and our outreach will
continue throughout the year.

The public response included supporters for all three options.
However, options A and B had almost exactly the same number of
supporters, while Option C was the most controversial and had
significantly fewer supporters than the other options.

Within the MITRE team, we also had advocates for all three options,
but the strongest preference by far was for Option A.  Also, the
proponents of Option C regarded Option A as their second choice.

Some of the biggest strengths of Option A are its fixed-length format,
its similarity to the current ID structure, and the fact that it
immediately "signals" a change to the entire community as soon as it
is used.  There are limitations to this option of course, such as the
large number of leading 0's that would be used for most IDs and
subject to typos, and the maximum of 999,999 IDs that can be supported
in a year.

Options B and C allow an effectively infinite number of IDs, so it
would be guaranteed that we would never have to change the CVE ID
Syntax again.  Option A is the only option that is limited to a finite
number of vulnerabilities per year, so this is a risk that must be
considered.

We believe that if the world changes to the point where the community
needs to track more than 999,999 vulnerabilities in a year, then (1)
it would represent such a seismic shift in vulnerability management
that a per-vulnerability ID scheme like CVE might not be appropriate
anyway (see the anti-virus industry for a precedent), and (2) even if
more than 999,999 vulnerabilities need to be tracked per year, it is
unlikely that so many vulnerabilities would need to be coordinated
across multiple communities.  So, even if there is a need for a
solution that addresses item 1, it probably would not be "true CVE"
because of CVE's role as a coordination ID.  To put it more simply, if
we all have to track a million vulnerabilities a year, then we're not
"doing CVE" any more.

While we hope that we will never have to change the ID syntax again in
CVE's lifetime, we also know that our past syntax decisions were not
future-proof (i.e., the choice of 4 digits in 1999, and the use of the
CAN- prefix before 2005).  Our more experienced Board members will
recall that we needed to move away from the CAN- prefix due to the
community needs for faster ID usage combined with such a large number
of disclosures that Editorial Board voting was no longer sustainable.
Using those experiences as a precedent, and the fact that Option A
represents an increase of two orders of magnitude compared to today's
syntax, we are comfortable that our choice will not be a problem for
at least the next 10 years and probably more; and if we need to make
another change, then it would be reflect and be driven by another
major shift in the larger vulnerability management landscape.

Of course, any option we choose will have different challenges for
adoption and transition, costs, and risks for the usage of incorrect
IDs.

We already have indications that some organizations might not be able
to fully handle a significant ID syntax change by January 2014.  Since
options A and C have an immediate change, Option B would best address
the needs of those organizations, since there would be no visible
change until we assign 10,000 IDs in a year.  The assignment of 10,000
IDs might not happen for another year or two while MITRE updates its
processes and infrastructure and ultimately increase our analytical
productivity, but at the very least, Option B would buy some time for
slow adopters.  Option B would also be preferable in other aspects of
ID management.  We decided that despite some of the advantages, there
were also some significant limitations to Option B, such as its
variable length, which would increase risks of truncation of 5-digit
IDs to 4 digits, make ID validation more complex, and the delayed
"signal" to the community that the syntax had been updated.  We
suspect that many affected organizations who prefer Option B because
they are not immediately able to implement Option A, would have the
resources to implement workarounds to support Option A.

If the world changes such that the community needs to coordinate with
1 million IDs or more, then Option A would be inappropriate.  In such
an environment, where automation would probably be used extensively,
Option C would be ideal for detecting transcription errors that could
cause major problems for fully-automated processes.  However, it is
clear that the current landcape is dominated by both humans and
machines, and the relatively limited human acceptance of Option C must
be taken into consideration.  Also, based on public feedback and our
own experience as the MITRE CNA, while transcription errors happen and
are annoying at best, they do not happen so frequently that they make
CVE unusable as a whole.  Also, with the check digit and unusual
format of Option C, there seem to be too many opportunities for errors
compared to the other options - for example, in addition to getting
the main "sequence" number incorrect, people could omit the check
digit or introduce a typo into the check digit itself even if the
sequence number is correct.  Finally, we did not see a unanimous
preference for Option C from the security tool vendor community, who
are most likely to see the effect of transcription errors on CVE
usability.  Therefore, we decided that Option C should not be
recommended.

In summary, we recommend Option A based on public feedback and
considerations of the diverse needs of the various communities that we
serve, in light of our assumption that the vulnerability management
landscape will not experience a fundamental shift in volume for at
least 10 years, and probably more.

The next step is to further engage the public at RSA, then have the
Editorial Board vote, and make a final decision at the end of March.
After the final decision, we will develop strategies and
recommendations for transitioning to the new syntax, with additional
assistance from the Editorial Board.

Thanks to the Editorial Board, and to the general public, for
continuing to provide us with such valuable input in a matter that may
not seem important on the surface, but has long-term implications.  It
is this spirit of community involvement and debate that has helped
make CVE so successful over these years.


Regards,
The MITRE CVE Team