Re: Concerns about CVE coverage shrinking - direct impact to researchers/companies

[Gsunde Orangen <gsunde.orangen () gmail com>]

I totally agree.
The concern addressed by Kurt initially is fully valid (for both
researchers and for companies that are not on Mitre's product/sources
list), so a new (better: additional) solution is required.
However, creating a new standard independently of CVE would be too
disruptive and be a disservice to the software industry.
I'd propose to work out a new solution together with Mitre, whilst
keeping the CVE IDs as today.
Since 2014, virtually unlimited number of CVE IDs can be assigned per
year [1], so a solution could be that
 - Mitre continues to assign 4 and 5 digit IDs as today
 - 6 digit IDs are reserved for the new process (hosted outside Mitre)
If more than one million vulnerabilities need to be addressed in one
year, we could follow the rule (odd digits -> Mitre, even digits ->
"other process")
> From Mitre's POC, this "other process" would become a "CNA", just with
its own policy and process definition, not prescribed by Mitre.
It would soon become clear to everyone (and all tools and products that
rely on CVE) where to look at for the authoritative vulnerability
information.

And yes: OWASP.org could certainly be a perfect host for that new "CNA"
- as Mark offered earlier ;-)

Gsunde

[1] https://cve.mitre.org/cve/identifiers/cve-ids.html


On 06.03.2016, 18:16 Robert Paprocki wrote:
> This thread should be the definition of Munroe's Law. Like Goodwin's Law, which states that the longer an online 
> conversation continues, the probability that it will involve Nazi analogies reaches 1, Munroe's Law says that 
> eventually any conversation about an existing standard reaches no conclusions other than to create a new standard. 
>
> https://xkcd.com/927
>
> > On Mar 6, 2016, at 08:16, Solar Designer <solar () openwall com> wrote:
> >
> > > On Sun, Mar 06, 2016 at 03:47:19PM +0000, op7ic x00 wrote:
> > > agree, the vanity hunting is going to be there but I suppose as with any
> > > bug ID that is going to happen.
> > > But beyond that I don't think it matters as much. In the end of the day if
> > > somebody can use OVI or OVE to identify their bug then at least we got some
> > > level of reference to look it up on google.
> >
> > Right.
> >
> > > I was toying with 4digit IDs that would be random enough, thats a
> > > possiblity too, the only problem is that there is a overhead of doing DB
> > > sorting and lookups to make sure their don't clash. Thats why ovi uses
> > > sequential numbers - its just easier to manage.
> >
> > Oh, you (would) use an actual database backend?  OVE currently uses a C
> > program with a tiny binary data file (to keep track of per-IP and
> > per-netblock consumption of IDs, as well as the current date and ID),
> > and the file is wiped clean (by this same program) on first access after
> > midnight.  I wrote this yesterday in response to the thread in here.
> >
> > For random IDs, if we wanted those, there are shuffling algorithms that
> > don't require storage yet guarantee unique numbers (until the target
> > range is exhausted) - they're good e.g. for IP ID and DNS sequence
> > numbers - although checking against an array of 10k numbers is almost
> > instant anyway (as far as this application is concerned).
> >
> > Anyway, this is getting off-topic.
> >
> > Alexander