[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CVE ID Syntax Change and Options

I'm happy to see that it has been decided to finally deal with the potential 10K problem. It is definitely realistic that we'll hit the 10K mark at some stage in 2013 or longer down the line. Looking at Secunia's statistics, I can see that we've previously come very close to handling >9999 vulnerabilities and that's not counting the unstable software, which we don't cover, or all the invalid issues that we've killed.

My immediate impression before reading the different options was to just add another digit (possibly 2 to be very much on the safe side), but keep the scheme as we all already know it (i.e. Option 2 or 3). It's my impression that this would also be the simplest for everyone to adopt and would provide the required coverage.


My comments to each suggested option:

Option 1: Year + arbitrary digits, no leading 0's

I like the idea of a CVE identifier having a fixed length with leading 0's. Occasionally, we see CVE identifiers included in reports where they have accidentally been truncated (e.g. CVE-XXXX-056 instead of CVE-XXXX-0560). The existing scheme makes it possible to spot if the CVE is wrong and while it does not allow to exactly determine what the number was supposed to be, it can be narrowed down. A scheme with no leading 0's would not make spotting wrong CVEs obvious.



Option 2: Year + 5 digits, leading 0's

My preference as already explained above. It's very similar to the format people already recognise and understand, it allows covering a sufficiently large number of vulnerabilities (I'm asking for a raise if we have to deal with more than 100K per year), and it should also be very cheap and simple to update existing parsers.



Option 3: Year + 6 digits, leading 0's

Would be my second choice, but I don't foresee the need for 6 digits. That may be the famous last words, but there would have to happen something very interesting for us to even get close to exhausting 5 digits in a year.



Option 4: Non-standard year + 4 digits

I don't like this one - it's too different from the currently recognised format. Of course, we shouldn't refrain from radically changing the current format if the general opinion is that it doesn't work, but for me it does - we just need more digits. I consider it a major advantage from a consumer standpoint that the actual year is part of the identifier and obvious.



Option 5: year + 4 hex digits

I don't like this one as it doesn't provide us with anything over Option 2. Yes, the length is the same as the current format, but as also pointed out, it will likely still require many parsers to be updated to deal with the extra characters. Furthermore, there will be less available CVE identifiers compared to Option 2. I also find it easier to remember a specific number when discussing a vulnerability with someone - "CVE-2012-01234" is easier to recall than "CVE-2012-04D2" (and in this case saying "4D2" fast sounds very similar to "42" so there is even room for confusion there).



Option 6: year + 4 alphanumeric

Same reasoning as for Option 5.



Option 7: CCE-Style (year + arbitrary digits + check digit)

Likely overkill and too academic - I do foresee many just omitting the check digit. I like the idea that it would be possible to spot typos, though, but it would require more to implement into current parsers. Also, even though it would ensure an unlimited supply of CVE identifiers, how many do we really need? We will all be putting in serious overtime if the world suddenly starts throwing 100K+ vulnerabilities at us each year.



Option 8: CERT-VU/JVN Style

Same reasoning as for Option 4 - I believe many consumers prefer the year to be clear and present in the identifier.



-- 

Med venlig hilsen / Kind regards


Carsten H. Eiram
Chief Security Specialist

Follow us on twitter
http://twitter.com/secunia
http://twitter.com/carsteneiram

Secunia
Mikado House
Rued Langgaards Vej 8
2300 Copenhagen S
Denmark

Phone   +45 7020 5144
Fax       +45 7020 5145


> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-
> editorial-board-list@lists.mitre.org] On Behalf Of Christey, Steven M.
> Sent: 6. november 2012 01:48
> To: cve-editorial-board-list
> Subject: CVE ID Syntax Change and Options
> 
> All,
> 
> 
> 
> As discussed in the Editorial Board teleconference on October 31, it
> 
> is time to update the CVE ID syntax so that CVE can support more than
> 
> 10,000 identifiers in a single year (the "CVE-10K Problem").
> 
> 
> 
> Some discussion was held on the Editorial Board list back in 2007, but
> 
> no official decision was reached or implemented (see
> 
> http://cve.mitre.org/data/board/archives/2007-01/threads.html).
> 
> 
> 
> However, it is now time to resolve this issue.  It sometimes causes
> 
> distractions in the larger Global Vulnerability Reporting (GVR)
> 
> discussions, and it is possible that MITRE could generate more than
> 
> 10,000 identifiers in 2013 due to additional staff and recent
> 
> process/infrastructure improvements.
> 
> 
> 
> It will take many consumers 6 months or more to fully adopt any new
> 
> syntax, so sufficient warning is required, and we will need to develop
> 
> a transition plan for the new syntax.  We will iron out the details
> 
> later.
> 
> 
> 
> Below are several options for ID syntaxes.  Please respond to the list
> 
> with your opinions about:
> 
> 
> 
> * suggestions for a different syntax?
> 
> 
> 
> * which syntax would be best for consumers?
> 
> 
> 
> * which syntax would be easiest/cheapest to adopt?
> 
> 
> 
> We are not holding any formal vote at this time.
> 
> 
> 
> 
> 
> Considerations for a Good Syntax
> 
> --------------------------------
> 
> 
> 
> For a new CVE ID syntax to be "good," it should have most (or all) of
> 
> the following properties:
> 
> 
> 
> 1) Large ID space, i.e., a large number of potential IDs that could be
> 
>    assigned.
> 
> 
> 
> 2) Usability by consumers - such as the ability to recognize that the
> 
>    ID is a CVE number, and to reduce confusion.
> 
> 
> 
> 3) Ease of adoption by consumers.
> 
> 
> 
> 4) Low maintenance/adoption costs for both consumers and providers.
> 
>    For example, some ID schemes could reduce memory/disk overhead, or
> 
>    it could be easy to extend regular expressions that are currently
> 
>    used to detect or manage CVD IDs.
> 
> 
> 
> 5) Delayed impact of the syntax change - since any change will have
> 
>    many unexpected effects on downstream consumers, we want to give
> 
>    people as much time to adjust to the new syntax as possible.  So,
> 
>    it may be favorable to use a syntax that doesn't appear to change
> 
>    until 10,000 identifiers are needed.
> 
> 
> 
> 6) Syntax version recognition - if possible, it should be clear to the
> 
>    consumer or an automated system as to which syntax version is being
> 
>    used for an ID - the old syntax, or the new syntax.  For example,
> 
>    ISBN numbers were originally 10 digits long, then    expanded to 13
> 
>    digits - so the length of the ISBN clarifies which version is being
> 
>    used.
> 
> 
> 
> 7) Future-proofing - if possible, the ID scheme could be flexible
> 
>    enough that future requirements do not force additional changes.
> 
> 
> 
> 
> 
> 
> 
> Option 1: Year + arbitrary digits, no leading 0's
> 
> -------------------------------------------------
> 
> 
> 
> Examples: CVE-2013-1234, CVE-2013-12345 (if 4 digits or less, leading
> 
> 0's would be used, e.g. CVE-2013-0056 instead of CVE-2013-56)
> 
> 
> 
> Impact: delayed until MITRE produces 10K IDs in a year
> 
> 
> 
> Number of IDs: 1,000,000 per year (assuming 6 digits)
> 
> 
> 
> Note: alphabetic sorting would not list CVE-2013-9999 and
> 
> CVE-2013--10000 next to each other.
> 
> 
> 
> 
> 
> 
> 
> Option 2: Year + 5 digits, leading 0's
> 
> --------------------------------------
> 
> 
> 
> Examples: CVE-2013-01234, CVE-2013-56789
> 
> 
> 
> Impact: immediate upon adoption (many existing parsers might
> 
> misinterpret "CVE-2013-01234" as "CVE-2013-0123" by assuming only 4
> 
> digits).
> 
> 
> 
> Number of IDs: 100,000 per year
> 
> 
> 
> Notes: this might not have extensive impact for some adopters,
> 
> e.g. some liberal regular expressions such as (CVE-\d+-\d+) would work
> 
> for both old and new syntax.
> 
> 
> 
> 
> 
> 
> 
> Option 3: Year + 6 digits, leading 0's
> 
> --------------------------------------
> 
> 
> 
> Example: CVE-2013-012345, CVE-2013-678901
> 
> 
> 
> Impact: immediate upon adoption (many existing parsers might
> 
> misinterpret "CVE-2013-012345" as "CVE-2013-0123" by assuming only 4
> 
> digits).
> 
> 
> 
> Number of IDs: 1,000,000 per year
> 
> 
> 
> Notes: this might not have extensive impact for some adopters.  For
> 
> example, some liberal regular expressions such as (CVE-\d+-\d+) would
> 
> work for both old and new syntax.
> 
> 
> 
> 
> 
> 
> 
> Option 4: Non-standard year + 4 digits
> 
> --------------------------------------
> 
> 
> 
> Example: CVE-1013-1234, CVE-3013-1234 (instead of using the current
> 
> year, a year before 1999 or after 3000 could be used once 10,000 is
> 
> reached in a single year)
> 
> 
> 
> Impact: delayed
> 
> 
> 
> Number of IDs: 100,000,000 overall
> 
> 
> 
> Notes: could cause user confusion (strange-looking IDs that are
> 
> assumed to be typos), but might have reduced adoption costs (many
> 
> current regular expressions would still work, ID is the same length as
> 
> the original syntax).
> 
> 
> 
> 
> 
> 
> 
> Option 5: year + 4 hex digits
> 
> -----------------------------
> 
> 
> 
> Example: CVE-2013-A9E4
> 
> 
> 
> Impact: delayed
> 
> 
> 
> Number of IDs: 65,535 per year
> 
> 
> 
> Notes: could cause user confusion (strange-looking IDs that are
> 
> assumed to be typos), but might have reduced adoption costs (length is
> 
> the same), although it would break regular expressions that assume
> 
> only digits.
> 
> 
> 
> 
> 
> 
> 
> Option 6: year + 4 alphanumeric
> 
> -------------------------------
> 
> 
> 
> Example: CVE-2013-ZW1K
> 
> 
> 
> Impact: delayed
> 
> 
> 
> Number of IDs: 1.7 million per year
> 
> 
> 
> Notes: could cause user confusion (strange-looking IDs that are
> 
> assumed to be typos), but might have reduced adoption costs (length is
> 
> the same), although it would break regular expressions that assume
> 
> only digits.
> 
> 
> 
> 
> 
> 
> 
> Option 7: CCE-Style (year + arbitrary digits + check digit)
> 
> -----------------------------------------------------------
> 
> 
> 
> Example: CVE-2013-12345-6 (the "6" is a check digit, following the
> 
> Luhn Check Digit Algorithm)
> 
> 
> 
> Impact: immediate
> 
> 
> 
> Number of IDs: Effectively unlimited
> 
> 
> 
> Notes: the check digit provides an easy way to automatically spot
> 
> typos in IDs, which happens in CVE multiple times per year (for
> 
> example, sometimes vendors release advisories with typos in the CVE
> 
> IDs).  The number of digits between the year and the check digit is
> 
> effectively unlimited, since the boundaries are marked by hyphens.
> 
> There may be user confusion, and people might leave out the check
> 
> digit entirely.
> 
> 
> 
> 
> 
> 
> 
> Option 8: CERT-VU/JVN Style
> 
> ---------------------------
> 
> 
> 
> Example: CVE#12345678
> 
> 
> 
> Impact: immediate
> 
> 
> 
> Number of IDs: 100,000,000 overall
> 
> 
> 
> Notes: this ID does not encode the year, which many consumers like,
> 
> since it is an approximation of when the issue became public.
> 
> 
> 
>
Page Last Updated or Reviewed: January 14, 2013