Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 20 Sep 2016 15:11:58 -0400 (EDT)
Subject: Re: Possible CVE for TLS protocol issue

Hash: SHA256


Our initial thought is that the essence of the issue is stated very
near the end of section 5.3 of the
document: "can derive the same master secret MS just by engaging in
the exact same computation." We are not sure whether it makes sense to
assign a CVE ID to a mathematical fact of that form. The vulnerability
seems to be that the TLS protocol definition allows rsa_fixed_dh,
dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh, but protocol
documentation such as RFC 5246 Appendix F does not explicitly point
out the severity of the outcome when any arbitrary installed client
certificate is compromised. It does, for example, say "For TLS to be
able to provide a secure connection, both the client and server
systems, keys, and applications must be secure," but it doesn't
delineate the level of connection insecurity that results from a
seemingly minor client insecurity.

Use CVE-2015-8960 for this vulnerability in the TLS documentation.

It is possible that other issues described in the
woot15-paper-hlauschek.pdf paper, such as issues related to handling
of key usage extensions, need their own separate CVE IDs.

In addition, as suggested by section 5.2, a product that originally
shipped with a compromised client certificate should, in many cases,
be considered a vulnerable product, regardless of whether that client
certificate has any known use for authenticating a client. We don't
know whether there are a huge number of products that have, for
example, installed test client certificates. Our initial thought is
that there should be a unique CVE ID for any product that satisfies
these criteria:

 - when the product was shipped, a default or recommended
   configuration had an installed client certificate and associated
   secret key that were both known to the general public (e.g., they
   were known by anyone who had a copy of the product)

 - the product can be used in a KCI attack, e.g., it meets all of the
   requirements of section 5.1.1

 - the product could realistically be expected to need secure
   communication with a server for which a certificate exists, from a
   commonly recognized Certification Authority, meeting the
   requirements of section 5.1.2 (e.g., this would often exclude a
   product that can establish TLS sessions only to a server operated
   by the vendor)

Post-shipment compromise of a client certificate's secret key is
currently outside the scope of CVE. The vulnerable behavior is
releasing a product where a client certificate is installed and its
secret key is already publicly documented.

Third-party suggestions for improving warning messages for
client-certificate installation are also currently outside the scope
of CVE. Although it might be nice for some products to have a warning
of "Are you completely sure that you want to install this client
certificate because no unauthorized party knows the secret key?" (or
similar), we don't want to have free-for-all CVE ID assignment. For
now, we'll let vendors have CVE IDs if they decide their existing
certificate-installation dialog is a security problem and they compose
a better dialog warning that's understandable by their customers.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


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.