Re: cryptographic primitive choices [was: Re: Microsoft Warns Customers Away From RC4 and SHA-1]

[Tim <tim-security () sentinelchicken org>]

> You cannot easily update an openssl 0.x version to 1.0.x if you ahd
> no symbol versioning set up as the symbols overlap and you would need
> to rebuild _all_ software using libssl, inlcuding libcrypto.


These are all good points.  SSL/TLS truly are used all over the place
and updating is not easy.


But I don't think the act of assigning a CVE has anything to do with
"is it hard to fix?", does it?  In assigning CVEs for weak crypto,
MITRE and the community is saying "there's a problem here".  Vendors
don't *have* to fix it.  Users don't *have* to listen to MITRE.  Will
it put pressure on vendors and users to fix?  Sure, of course, and
that's a good thing.  But difficulty of providing backward
compatibility should not be a consideration in my view.


With that said, I still stand by previous argument that we must assign
CVEs for this kind of thing judiciously, and only when there's a
demonstrable attack.  At least a sound argument must exist, in theory,
that a real attack could be conducted.


And a final note about backward compatibility:  If I use an SSL/TLS
library that supports RC4, but only chooses RC4 as a last resort
during negotiation, aren't I ok?  I was under the impression that the
SSL/TLS handshake validated that no one could tamper with the list of
supported cipher suites advertised by each end of the conversation.
So, if a library only falls back to RC4 for compatibility, then I
don't think such a thing deserves a CVE.  The CVEs should be assigned
to implementations that *prefer* weak ciphers or support *only* weak
ciphers.

Cheers,
tim