[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201403102137.s2ALboaZ015057@linus.mitre.org>
Date: Mon, 10 Mar 2014 17:37:50 -0400 (EDT)
From: cve-assign@...re.org
To: hanno@...eck.de
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: When is broken crypto a vulnerability?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Now there are all kinds of applications doing one of the following
> things:
> b) Provide an option to use AES, but they don't use it and still
> create legacy "encryption".
> I think it should be noncontroversial that b) is a vulnerability and
> thus should get a CVE. Any disagreement here?
It's not completely clear what you mean. If it were a logic error in
the code, e.g., menu choice 2 of "AES encryption" is selected but the
code calls the function intended for menu choice 1 of "standard
encryption," then a CVE could be assigned to the specific codebase
that has that logic error.
There may be some types of UI issues that would not have CVE
assignments. For example: "AES encryption" is grayed out because the
product actually doesn't yet contain an implementation of AES, but the
grayed-out status is not as prominent as it could be.
> I could accept it if applications provide this as a compatibility
> option when there's a clear sign to the user that it's not secure
There's also the question of whether the security properties are well
known, and the product does not contain any direct misrepresentation
(e.g., stating that standard ZIP encryption is "equivalent to PGP" or
"uses 2048-bit keys").
http://en.wikipedia.org/w/index.php?title=Zip_%28file_format%29&diff=15369348&oldid=15369279
suggests that the security properties have been known outside the
research community since 2005, and probably the security properties
have been widely known for much longer than that. Anyone making a
reasonable effort to determine whether standard ZIP encryption was
suitable for their use case could find applicable information.
As a side issue, one common use case for ZIP encryption is exchanging
files (such as virus samples) that would otherwise trigger unwanted
content detection by a mail system's scanner. In other words, a use
case does not necessarily have anything to do with confidentiality.
> c) Default to legacy "encryption"
Sometimes there are CVE assignments based on a general concept of "an
insecure option should not be the default" but here there's the
complication that only the insecure option has widespread cross-vendor
compatibility. One needs to consider the support costs of changing the
default. It's a usability decision for each vendor, based in part on
what they know about whether their customers use encryption for
confidentiality or for a different reason.
"It would be better for everyone if every vendor changed to a good
algorithm" isn't equivalent to "there should be a CVE for every vendor
who hasn't changed."
> calling it "ZipCrypto(insecure)" or "insecure crypto" or something alike
It doesn't seem appropriate to make CVE assignments on the basis that
a UI omits information that is arguably well known, and is not
specific to that one product. As an extreme example, every occurrence
of an http URL in a web browser could have a tooltip stating
"http(insecure)" or "insecure http," and a subset of web users would
then be safer. There is some subset of ZIP users who have dangerously
incorrect expectations about what encryption means, and one may want
to start an outreach effort toward ZIP product vendors who could
attempt to address that within their UIs. This does not necessarily
mean that the CVE project has a role in that outreach effort.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTHi9BAAoJEKllVAevmvmsLbIIALyptMlS+u9bXLtNnnoPbUW8
ADWmZ2+q642oOA8ZOnHkOqOubxS1FBTIvNLou11TENJa25i4JkAtKU5nwi8PPX1E
pUCnXVGubH7FgDnsdaDiZzN4Jk00llgGrRzZDPXR0daIj9dJ3kIOK5oNPdmO+Vdi
cnCQahF7eG2XtyC8oyIDZibIMVGugDR6dYGcLZq7NYwTvUQ7Qn6sIiAlpu6aadOC
xo41BVUCaqsc3MlCXPefhmgwY24VWhtA5Ef4lgLUCLLw9GQwyB8bn/kNAZUuZC2r
KOvS7tuRyJnAnB3MfzEYxRnF7cR/gLnUwrvcernx0DFBNlbXrv/J75chVxGEZsE=
=g1LU
-----END PGP SIGNATURE-----
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.
