Date: Tue, 20 Sep 2016 15:11:58 -0400 (EDT) From: cve-assign@...re.org To: kseifried@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Possible CVE for TLS protocol issue -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://kcitls.org/ Our initial thought is that the essence of the issue is stated very near the end of section 5.3 of the https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf 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 http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJX4YgdAAoJEHb/MwWLVhi2ygQP/0RLWIentfu+p3xBdmQ4YP5l sDb5xUVOsECGnFDEF2B/LnFRSk1nV8EcWPk+U8wB71ztqiLZ6y8mHRwb22P95Lef 3fMcLhJ7GTNgPMoKXS4bNbUD4qKJsM1Rq4PR5mPrEh3XfSe4Ts4gsElwzmSOyf3k RODrZSymGOGl+TGHc0L8LpdUB7RPpsBlUcCw7kLXn82AKOPZBT8aoJFDpXcX+Ome sNU8AiiZbXpWtuJjZ3x5oQnGztkOIxTcI8zANZcUWDUNK1tFOKieiTyVWkx7dJ49 yN07vfsWCQSKSIUd+pMRawXsaOSO6zTUufJoj9SbfNWtma5q60UythHS507afiq6 AiIalyG3jYLg5Q9puSmbrfOFCsZ99slGZPfc683rwavUQ0M+kmA2HDwdd2NGt5I4 wRO8p7wX02fH+4xLA9t3bbq+TYqR1vNnj6QjErjB9vHrVdTGJJIiMg+WD2QoH+PQ gQtk3p6tKI5awsnXu73dd7/G3Rd5mFoTX0xfygHca7z7DLirFSZ+hcx4/3+FIOyZ ZqHHVgxyt2awxyam0iudp1udqEOenIhpNNZqnTaAFaD6aENmMW0CV2SSSf6LkD3B x8s5RwE+uX1CKlhH1gkDqx7df6gFeUnNvcwoc5POF0JolevpHrtXSbwBHFFGeT6S AsswVVMQxPKkbxx40iqM =zIPv -----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.