Editorial Board Teleconference - October 31, 2012
=================================================
Attendees
---------
Editorial Board:
- Kent Landfield, McAfee
- TK Keanini, nCircle
- Brian Martin, OSVDB
- Art Manion, CERT/CC
- Ken Williams, CA
- Adam Shostack, Microsoft
- Harold Booth, NIST
- Andy Balinsky, Cisco
Non-Board:
- Dave Waltermire (NIST)
- Kurt Seifried, Red Hat (representing Board member Mark Cox)
MITRE:
- David Mann
- Steve Christey
- Bob Martin
- Jonathan Evans
CVE Scope
---------
David Mann reviewed the definition of CVE's scope in terms of sources
and products, as covered in more detail in mailing list discussions.
David asked for final feedback on the list of sources and products.
Nobody had additional feedback.
Harold Booth asked whether this list would remain static, and whether
there will be an opportunity for Board members to provide additional
suggestions for potential sources. MITRE intends to review and revise
the list periodically . perhaps once a year - but Board members can
also provide input, which will ensure a feedback loop to ensure
consistent review of this list between MITRE and the Board.
ITSAC Global Vulnerability Reporting (GVR) Recap
------------------------------------------------
David Mann presented recent GVR activities, including the GVR panel at
the ITSAC conference as held earlier in October. ITSAC topics
included the notion of promiscuous or global ID syntax, the need for
changes to CVE ID syntax to support more than 10,000 IDs in a year,
MITRE.s intention to help in GVR discussions without leading it. Kent
Landfield stated that the ITSAC panel was a good starting point and a
useful lead-in to the upcoming meeting in Kyoto.
CVE ID Syntax Changes
---------------------
Steve Christey covered potential changes to the current CVE ID scheme,
which only supports 10,000 unique identifiers per year (the .CVE-10K
Problem.). With MITRE’s content production team growing, and with
various process improvements taking place, it is possible that in late
2013, CVE could exceed 10,000 identifiers for that year.
There is a working assumption that any modification to the current
scheme will force changes by CVE consumers and providers. However,
the community was able to handle the "CAN-" prefix change without much
problem.
Multiple criteria for a "good" syntax were outlined, including a large
ID space, good usability and ease of adoption by consumers, low
maintenance/adoption costs for providers, and immediate versus delayed
impact of any scheme change. For example, some schemes would not have
any apparent changes until 10,000 identifiers are produced in a single
year, which could give some extra time for providers to adjust.
Several options for ID syntax were provided. Details will be posted
to the mailing list for full discussion by all Editorial Board
members, but they are summarized below:
1) Year plus arbitrary digits, no leading 0.s (examples:
CVE-2013-1234, CVE-2013-12345; CVE-2013-0056 would be preserved)
2) Year plus extra digits, with leading 0.s (e.g. CVE-2013-01234 or
CVE-2013-012345)
3) Year-plus-4: non-standard year plus 4 digits (e.g. CVE-1013-nnnn,
CVE-3013-nnnn)
4) Year-plus-4: Year plus 4 hex digits (CVE-2013-A9E4)
5) Year-plus-4: Year plus 4 alphanumeric (CVE-2013-ZW1K)
6) Year plus arbitrary digits plus check bit, aka CCE style
(CVE-2013-12345-6)
7) CERT-VU/JVN style (CVE#12345678)
While there was insufficient time to discuss the subtleties and
ramifications of each scheme, here were some themes:
1) Backward compatibility for older IDs was needed . i.e., for CVEs
released before the ID change, they should not necessarily be
renumbered. This would preserve usability of IDs in older academic
papers, advisory documents, mailing list and web site archives, etc.
2) Some participants were supportive of making the new ID scheme
appear as similar as possible as the old scheme. This would minimize
adoption costs and reduce consumer confusion.
3) Kent Landfield talked about adding additional digits to the end.
He believed this would be the least impactful from a coding
perspective for just about anybody. This wouldn't change the sorting,
display, usage, or retrieval of IDs - mainly the same format. For
some of the newer or more radical syntax, this would change how CVE
numbers are parsed initially, which would have a larger impact on the
community, and it would be less intuitive for users. It would
introduce new issues they have to deal with (e.g. bad year encoding).
It would lose the ability to discern identifiers from a human
perspective. The "New School" items (i.e., CCE-style, CERT-VU-style)
would require more effort for adoption.
4) Art Manion explained that the CERT-VU structure served a different
purpose; they did not want IDs to be sequential or to reflect when an
ID was assigned. There were underlying mathematical formulas, but
they helped CERT/CC to ensure that a unique ID could be generated.
Art did not think that these requirements were relevant to CVE.
5) Harold Booth asked other Board members what their requirements for
the ID are. There was not sufficient time to explore this with all
participants, however.
6) TK Keanini suggested that the proposed schemes did not have an
important property. He suggested that a "CVE 2.0" ID syntax should be
able to make it very obvious to consumers that the ID is not a "CVE
1.0" style ID. To support backward compatibility, a CVE-2.0
identifier could add a suffix to the end of a CVE-1.0 style
identifier. As long as the new format for CVE-2.0 identifiers is
"outside the boundaries" of a CVE-1.0 identifier, then all CVE-1.0
identifiers would be backward-compatible.
7) Adam Shostack agreed that the old-style format should not be
broken. (After the telecon, David Mann told the CVE team that ISBN
numbers were extended from 10 to 13 characters to increase the space
of potential identifiers while preserving backward compatibility, and
it was easy to distinguish between identifier versions based solely on
their length.)
CVE ID Transition Plan
----------------------
Assumption - many consumers/providers will need 6 months or more to
fully adopt a new syntax. MITRE could support old and new IDs
beginning in January 2013, and possibly move to only new IDs for
January 2014. However, simultaneous support for dual schemes could
still have an impact on CVE providers, since some consumers would
begin using (or searching for) new IDs as soon as they were published.
Andy Balinsky asked if the idea for the new ID scheme was to have it
finalized and up-and-running by 2013. From Kent's perspective, it
could take 8 or 9 months for products to adopt and get supported.
Also need a PR effort to get the community to understand that CVE 2.0
is a new thing that requires some preparation.
Kurt Seifried advocated use of a 6-digit approach with leading 0
characters, and thought that an alphanumeric scheme would not work
well.
FIRST GVR Summit Discussion
---------------------------
David Mann told the Board about the upcoming Forum of Incident
Response and Security Teams (FIRST) technical colloquium in Kyoto,
Japan, from November 13 to 15. This colloquium will feature a "Future
of Global Vulnerability Reporting Summit," hosted by JP-CERT and the
Japanese IPA.
A detailed description and request for comments will be posted to the
mailing list.
MITRE will attend this summit, but we would like to get feedback from
Editorial Board members before then, with the hope of representing an
Editorial Board consensus at the summit. The MITRE CVE team believes
that FIRST is the appropriate venue to have GVR discussions, but also
emphasized that MITRE CVE itself needs to continue to focus on
achieving consensus on its defined scope - i.e., focusing on the
English-based software market, using a list of full and partial
coverage sources and products, based on input from the Editorial
Board. MITRE recognizes the effort that Masato Terada and JP-CERT/IPA
has put into supporting CVE, such as providing English translations
for Japanese-only product vulnerabilities and advocating a global
dialogue about vulnerability identifiers.
Note that disclosure practices appear to differ by region. For
example, disclosure in Japan is largely coordinated, and there is no
equivalent to Bugtraq and the full-disclosure movement. With
regulatory and cultural differences, disclosure practices may evolve
differently.
We have identified 3 main options for approaching the GVR problem in
the coming months. Additional details, along with strengths and
limitations of each option, will be posted separately to the mailing
list.
Option 1 - "Global CVE" - borrowing from the current relationship
between CVE and JP-CERT, establish relationships with other CERTs or
ID-issuing organizations in foreign markets, then train them as
Candidate Numbering Authorities (CNAs).
Option 2 - "Create a new ID Syntax" - Extend the current GVR
discussions for "promiscuous" IDs to create a new ID syntax that could
be used globally.
Option 3 - "Wait, Let Markets Mature, and Reassess" - Let disclosure
practices and coordination continue to evolve in different markets;
postpone definition of a new ID scheme until there is more maturity
and clarity.
** Board Discussion **
Harold Booth - doesn't think options 1 or 2 are feasible; is working
within IETF on a format for exchanging vulnerability information that
is similar to CVRF but also contains support for cross-referencing
different ID schemes. He will post a pointer to the Editorial Board
mailing list.
Kent - the Kyoto meeting is intended to start the discussion, use the
3-day meeting to discuss the issues in depth, get perspectives beyond
the USA, and begin the dialog.
Art Manion - agrees that MITRE/CVE scope cannot be global. FIRST is a
good place to try to start off - some non-US opinions would be good.
Since the 2012 ITSAC meeting, a way forward might be allow the markets
to develop. Asked Harold Booth - is there a format to relate
vulnerabilities and share information?
Harold will forward his ideas (IETF track) to the Editorial Board
mailing list. It is similar in concept to CVRF but contains a
separate section for aliasing, which would support a global ID scheme.
Harold believes that neither Option 1 nor Option 2 is feasible at this
time. Dave Waltermire suggested that part of the outcome of this
effort might be to support different vulnerability-exchange formats.
Andy Balinsky asked whether there was synergy between the new CVE ID
scheme and what could happen in GVR? Ideally, CVE could follow the
same scheme that is adopted by GVR. Steve Christey said that the
timing isn't right. The CVE-10K will happen soon (maybe in 2013), and
the global ID scheme could take years to develop. So, the timing is
not ideal. Also, the current issues with CVE IDs can be distractions
in the larger GVR discussions, so addressing the CVE ID problems now
would be helpful.
The teleconference ended with a comment implying that the delay
between Editorial Board meetings has been too long lately. MITRE will
take this into consideration.
