On Tue, Oct 27, 2020 at 01:59:35PM +0000, Salz, Rich wrote:
> Having worked on OpenSSL for many years, the absolute worst thing you can do is not respond to reported vulnerabilities. Even if it???s just an auto-reply that says ???thanks we got it.???
>
> I also think it would be worth pointing out more strongly that we are interested in *protocol* errors, not *implementation* errors, and making that distinction clear.
Again, just to re-emphasize my desire that three should be an open discussion list for
vulnerabilities (vulnerability-discuss), because IMHO this is one of the likely repeatedly
incurring points of contentions as to where to draw the line. Which IMHO needs to be explored.
One initial definition might be "implementation error is one that can be fixed without
changing the protocol spec text" (i guess, i have not seen a better definition).
So lets say i have seen enough cases where routers stopped forwarding any traffic because
they ran out of memory because someone attacked the router creating to much protocol
state. Lets pick your poison, in my case it was easily user generated multicast state,
others may prefer BGP or IGPs.
So... should the protcol spec have a requirement stating that implementations
MUST ensure this can not happen, and - oh, go figure out how to do that, not a
protocol issue ?
In patents, patent protection is only granted when the description is
sufficient to build a working model. So if you want to claim that a protocol
is not at fault for an attack, its description needs to be sufficient to
make it clear how to build a working model protecting against the attack.
If you apply that guideline to IETF protocol specs, you will draw blanks all
over the place. At least in routing.
Cheers
Toerless
