Re: Possible CVE for TLS protocol issue

[cve-assign () mitre org]

-----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-----