----- Original Message ----- > From: "Hubert Kario" <[email protected]> > > ----- Original Message ----- > > From: "Kathleen Wilson" <[email protected]> > > > > == For this batch of root changes == > > > > We are still investigating if we should use this possible solution for > > this batch of root changes. Please stay tuned and continue to share data > > and test results that should be considered.
So I've analysed the data. I simulated removal of 11 roots mentioned in bugs linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1021967: Entrust.net Secure Server Certification Authority 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39 GTE CyberTrust Global Root 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74 ValiCert Class 1 Policy Validation Authority E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E ValiCert Class 2 Policy Validation Authority 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6 ValiCert Class 3 Policy Validation Authority 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB NetLock Uzleti (Class B) Tanusitvanykiado 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF NetLock Uzleti (Class C) Tanusitvanykiado E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B VeriSign, Inc. / Class 3 Public Primary Certification Authority A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2 Sociedad Cameral de Certificacion Digital CB:A1:C5:F8:B0:E3:5E:B8:B9:45:12:D3:F9:34:A2:E9:06:10:D3:36 TDC Internet Root CA 21:FC:BD:8E:7F:6C:AF:05:1B:D1:B3:43:EC:A8:E7:61:47:F2:0F:8A The data (and as such, the certificates) were collected between 11th and 19th of July 2014 and did include Alexa top 1 million domain names as of 10th of July. With the above certificates: Server provided chains Count Percent -------------------------+---------+------- complete 359484 61.6908 incomplete 29543 5.0699 untrusted 193692 33.2393 Without the above certificates: Server provided chains Count Percent -------------------------+---------+------- complete 359265 61.6532 incomplete 29663 5.0904 untrusted 193791 33.2563 Change (without-with) Count -------------------------+--------- complete -219 incomplete +120 untrusted +99 Attached are the lists of those servers. (disclaimer: trust chain building did ignore host names, extended key usage limitations, and used OpenSSL for chain building) I've also gathered a bit extra statistics. The use of key sizes in CA certificates (count is number of chains that use them): With the 1024 bit roots: Chains with CA key Count Percent -------------------------+---------+------- ECDSA 256 2 0.0004 ECDSA 384 2 0.0004 RSA 1024 1776 0.399 RSA 2045 1 0.0002 RSA 2048 443399 99.619 RSA 4096 16134 3.6248 Without the 1024 bit roots: Chains with CA key Count Percent -------------------------+---------+------- ECDSA 256 2 0.0004 ECDSA 384 2 0.0004 RSA 1024 1539 0.3459 RSA 2045 1 0.0002 RSA 2048 443308 99.6229 RSA 4096 16121 3.6228 it has limited effect on overall security of connection (if we assume 80 bit level of security for both SHA1 and 1024 bit RSA and ignore signature algorithm on the root certs): With weak roots: Eff. host cert chain LoS Count Percent -------------------------+---------+------- 80 398413 89.5119 112 46680 10.4876 128 2 0.0004 Without weak roots: Eff. host cert chain LoS Count Percent -------------------------+---------+------- 80 398304 89.5093 112 46680 10.4902 128 2 0.0004 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: [email protected] Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
