Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
I believe this plan would have poor side effects. For example, if Apple ships clients with a broken ECDSA implementation [0], a server cannot detect detect if a connecting client is an Apple product and avoid the use of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes unsafe for anyone to use anywhere. [0]: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith br...@briansmith.org wrote: Please see https://briansmith.org/browser-ciphersuites-01.html First, this is a proposal to change the set of sequence of ciphersuites that Firefox offers. Secondly, this is an invitation for other browser makers to adopt the same sequence of ciphersuites to maximize interoperability, to minimize fingerprinting, and ultimately to make server-side software developers and system administrators' jobs easier. Suggestions for improvements are encouraged. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
On 08/15/2013 03:21 AM, Gervase Markham wrote: On 15/08/13 01:19, Robert Relyea wrote: On 08/09/2013 02:57 AM, Gervase Markham wrote: Can an NSS hacker please tell me, in the fashion of the attempt by the IE representative below, what types of certificate NSS accepts for making SSL connections? What features must the cert or chain have or not have? Or, if this is a PSM question, tell me that :-) Gerv I think you already have the answer, but here's the basic: The code to determine the type a cert is in in certdb.c called cert_ComputeCertType(). For those following along: http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/certdb.c#l489 It's rather complex to allow historical issued certificates to function: If the cert has neither an extended key usage or a netscape cert extension, then the cert is considered legacy and OK for use for everything except code signing (Email/SSL client/SSL Server). Do we have any idea of the compatibility impact of changing that behaviour so that we do not accept such certs for authenticating SSL servers? That's an instrumentation issue. It was true back in 1995/6 when the code was added I don't know how true it is today. My guess is the biggest compatibility issue is self-issued certs, not CA issued certs... but then again most of those are self-signed... We should also check the use of the NS Cert Type extension. My guess is in the real world, if it exists, it's data is mirrored by basic constraints and extended key usage. If the cert as either an extended key usage or a netscape cert extension, then the cert must have the SSL_Server type set. Exception, if it has the extended key usage and the Govt_approved, it is assumed to also have SSL_Server. The code has some comment that COMMODO needs this behavior until 2020. If the cert has both an extended key usage and a netscape cert extension, only one of these need to indicate that it's an SSL_Server cert. Also, the cert can't be a CA cert (SSL Server+CA maps to a CA that can issue SSL_Server certs, not an SSL_Server cert). So the logic of that code block, as I read it, is: SSL_Server == !(NS_Type_Extension || EKU_Extension)// 608-621 || NS_Type_SSL_Server// 516 || !BC_isCA ( EKU_Server_Auth// 553-562 || NS_Govt_Approved// 563-576 ) SSL_Client == !(NS_Type_Extension || EKU_Extension)// 608-621 || NS_Type_SSL_Client// 516 || EKU_SSL_Client_Auth // 577-586 SSL_CA == NS_SSL_CA// 516 || BC_isCA ( !(NS_Type_Extension || EKU_Extension) // 608-621 || NS_Type_Email_CA// 531-537 || EKU_SSL_Server_Auth // 553-562 || NS_Govt_Approved// 563-576 || EKU_SSL_Client_Auth // 577-586 ) Email== NS_Type_Email// 516 || !(NS_Type_Extension || EKU_Extension) // 608-621 || (NS_Type_SSL_Client Has_Email_Address) // 523-530 || (EKU_Email_Protect !BC_isCA) // 538-552 The reason for line 523 is because S/MIME usage predates EKU_Email_Protection, so SSL_Client certs were used. Email_CA == NS_Type_Email_CA // 516 || BC_isCA ( !(NS_Type_Extension || EKU_Extension) // 608-621 || EKU_Email_Protect // 538-552 ) Code_Sign== NS_Type_Object_Signing // 516 || (EKU_Code_Sign !BC_isCA) // 587-596 Code_Sign_CA == NS_Type_Object_Signing_CA// 516 || (EKU_Code_Sign BC_isCA)// 587-596 Time_Stamp == EKU_Time_Stamp // 597-601 Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. NOTE that the Netscape Cert Type extension can set any bit in NSCertType, including bits that didn't exist at the time the cert was issued. (OR even combinations of bits you couldn't get otherwise, like both SSL_SERVER and SSL_SERVER_CA. OCSP_Resp== OID_OCSP_Responder // 602-606 || is_Any_CA_Type !(NS_Type_Extension || EKU_Extension) // 608-621 Questions: * Line 608ff: why does this part of the code use two ways of determining whether a cert is a CA cert? Certs that have neither a NS_Cert extention nor an EKU Extension are most likely a primitive certificate (primitive in it's use of the standards). CA certs are particularly likely to be
Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
On 15/08/13 19:01, Robert Relyea wrote: That's an instrumentation issue. It was true back in 1995/6 when the code was added I don't know how true it is today. My guess is the biggest compatibility issue is self-issued certs, not CA issued certs... but then again most of those are self-signed... Are we currently gathering cert data using Telemetry? Perhaps this could be added. Time_Stamp == EKU_Time_Stamp // 597-601 Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. What is the difference between these two? Looking at the wording, they seem identical - EKU stands for EXT_KEY_USAGE... It seems the conditions under which a cert is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the other types... I'm not sure what you mean by this. I mean that (for certs with no NS extension and no EKU) the cert is given type EXT_KEY_USAGE_STATUS_RESPONDER if CERT_IsCACert() returns true. This is a more expansive check than merely seeing if basicConstraint.isCA is true - which is what is checked for the other cert types. I am talking about lines 610-618. two. It's been several decades since we have the general constraints and the NS Cert extension is basically redundant in face of that, so I think it would be good to look at deprecating the support for parsing NS Cert extensions altogether. (It may even be safer to do this than to drop support for certs with neither extension). Feel free to file a bug :-) Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
Time_Stamp == EKU_Time_Stamp // 597-601 Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. What is the difference between these two? Looking at the wording, they seem identical - EKU stands for EXT_KEY_USAGE... One is the bit set in the Netscape Certificate extension and the other is the oid in the EKU extension. The point is that the Netscape Cert type extension can set any bit in our certType. It seems the conditions under which a cert is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the other types... I'm not sure what you mean by this. I mean that (for certs with no NS extension and no EKU) the cert is given type EXT_KEY_USAGE_STATUS_RESPONDER if CERT_IsCACert() returns true. This is a more expansive check than merely seeing if basicConstraint.isCA is true - which is what is checked for the other cert types. I am talking about lines 610-618. Right if you don't have a NS cert type or EKU extension, then you likely have a primitive cert, which requires a whole lot more futzing to tell if it's a CA cert or not (basically the extra futzing is did someone tell us this is a CA cert in the certdb, which in general happens with root certs primarily). two. It's been several decades since we have the general constraints and the NS Cert extension is basically redundant in face of that, so I think it would be good to look at deprecating the support for parsing NS Cert extensions altogether. (It may even be safer to do this than to drop support for certs with neither extension). Feel free to file a bug :-) It depends on how critical it is to parsing BR certs. Is it important to know a CA is only treated as a CA if it has basic constraints (barring the database override). I was offering that it might be possible to remove it, but I don't have a pressing need to remove it.;). Gerv smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Custom TLS Extensions in NSS (Patch in Progress)
I have opened an issue on bugzilla, with patch attached: https://bugzilla.mozilla.org/show_bug.cgi?id=905848 On Aug 14, 2013, at 6:05 PM, Daniel Jackoway dani...@matasano.com wrote: Ok, I'll get a patch on bugzilla soon. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
