Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20131115222314.GM28665@sentinelchicken.org>
Date: Fri, 15 Nov 2013 14:23:14 -0800
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: cryptographic primitive choices [was: Re:
 Microsoft Warns Customers Away From RC4 and SHA-1]

> 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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.