Re: CVE Request New-djbdns: dnscache: potential cache poisoning

[P J P <ppandit () redhat com>]

+-- On Thu, 20 Feb 2014, cve-assign () mitre org wrote --+
| However, lack of use of SipHash was not a "mistake." Almost any product can 
| be improved by addressing more classes of threats, but this does not 
| establish that a mistake occurred.

  So now SipHash is 'the only' way to avoid hash collision ever?

| Those CVEs were based on announcements by vendors who were original
| authors of pieces of software. Our first reply already mentioned that
| those are an entirely separate case of CVE inclusion.

  So, if original author says it's a flaw then it's a flaw, otherwise not? 
 
| are, in general, a major complication for CVE. However, at this point,
| keeping "algorithm-choice improvement after a fork" outside the scope
| of CVE seems to be, on balance, the better alternative.

  That's not convincing, but anyways, I'm sure you know better than me. Thank 
you for the explanation. I appreciate it.

Thank you.
--
Prasad J Pandit / Red Hat Security Response Team