CVE ID Issuance Strategies Using the New ID Syntax

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

All,

Now that the variable-length Option B has been selected, we are
seeking the Board's input on several questions.  We are seeking the
Board's assistance in communicating the syntax change, which will be
covered in a separate thread.  This email regards the best strategy
for issuing CVE IDs beginning with the "CVE-2014-" prefix, for the
2014-2015 transition year.

For issuing CVE IDs, we see two significant questions:

- whether we should avoid assignments of CVE-2014-0001 through
   CVE-2014-0999 (avoiding any "leading zeroes")

- whether issuance should reduce the risks in which 5-digit IDs might
   be inadvertently truncated to 4-digit IDs ("truncation mitigation")


LEADING ZEROES
--------------

Beginning in 2014, should CVE IDs follow the practice of previous
years and begin with CVE-2014-0001, or should they begin with
CVE-2014-1000?

Some Board members have suggested that we could avoid using leading
0's in CVE IDs, i.e., to start with "CVE-2014-1000" instead of
"CVE-2014-0001".  This approach might simplify some code that outputs
CVE IDs.  We have observed third-party code that represents
"CVE-2013-0123" not as a string, but as two integer column values:
2013 and 123. However, it is not clear whether our requirement of
leading zeroes on output poses any significant technical cost.

Besides the possible implementation costs for some parties, are there
any other benefits to avoiding leading zeroes?

Starting with CVE-2014-1000 would reduce the space by 999 IDs before 5
digits are needed, which would reduce the amount of time that vendors
have to fix their implementations, possibly by a couple of months.

MITRE recommends continuing the practice of the past 14 years, and
using the leading zeroes for only the first 999 IDs.


TRUNCATION MITIGATION
---------------------

For 2014, should our issuance strategy mitigate the potential risks
when CVE IDs with 5 or more digits are issued, but the IDs are not
properly handled by non-compliant implementations that assume only 4
digits?

If a legitimate 5-digit ID is inadvertently truncated to a 4-digit ID,
then this would cause incorrect CVE IDs to be used and adversely
affect the exchange of vulnerability information.  For example,
suppose that both CVE-2014-1000 and CVE-2014-10007 are issued in 2014,
and an advisory refers to CVE-2014-10007.  An implementation that
assumes 4 digits might inadvertently convert CVE-2014-10007 into
CVE-2014-1000, which would be a completely different ID for a
different vulnerability.

Even if our communication strategy is highly successful, there is
still a risk that either (1) some developers will not learn about the
ID syntax change, or (2) some developers will not be able to fix their
code in time.  Based on some research we conducted earlier this year,
we have seen a number of CVE-ID implementations in which 4 digits are
assumed.  The 4-digit assumption might be most prominent in code that
(1) extracts or parses CVE IDs, or (2) outputs CVEs assuming a
specific format or length.

To minimize this risk, during 2014 only, we could avoid assigning a
relatively small number of 4-digit IDs if there is a reasonable chance
that a different, 5-digit ID could be assigned that has a risk of
being inadvertently truncated to the original 4-digit ID.  For
example, the first 5-digit ID to be issued would be CVE-2014-10000;
since this could be truncated to CVE-2014-1000, we could avoid
assigning CVE-2014-1000 entirely.  We could use this approach for a
"protecting block" of IDs, such as CVE-2014-1000 through CVE-2014-1199
(200 IDs).  This means that any 4-digit truncation of CVE-2014-10000
through CVE-2014-11999 would not map to a valid ID.  Since the block
of 2000 "protected" 5-digit IDs will almost certainly include IDs for
high-profile vulnerabilities, users and developers of truncating
implementations are likely to be alerted to the problem quickly.
Also, the CVE-2014-1000 to CVE-2014-1199 protecting block is small
enough (200 IDs) that it would make a negligible difference (2%) in
the likelihood of reaching 10,000 IDs in 2014. Thus, there is an
attractive 10-to-1 tradeoff between the number of protected IDs and
the size of the protecting block.  Our only known disadvantage is that
reaching CVE-2014-10000 even 2% faster might adversely affect someone.

The exact size and implementation of the protecting block would be
determined later.  If truncation mitigation is desired, then some
potential ways to implement protecting blocks include, but are not
necessarily limited to, (1) not assigning the protecting block IDs
(e.g. CVE-2014-1000) at all, or (2) assigning protecting block IDs,
but providing a description that emphasizes that the ID is not for
public use and might indicate a truncation error.

At this time, MITRE does not have a specific recommendation regarding
whether truncation mitigation should be pursued, and we welcome
opinions from the Board.

We would appreciate everybody's feedback on these questions.


Regards,
The MITRE CVE Team