Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On 4/25/14, 9:18 AM, Zack Weinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2014 09:59 AM, Erwann Abalea wrote: Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. That doesn't seem like enough of a justification to me. It may not be mandatory, but please explain why it is not *necessary* (i.e. why no security guarantees depend on it). Lets pretend for the sake of the argument that you are an attacker and can modify the value of the AKI (assume that the AKI is not signed by the CA). You will notice that this field is NOT used to determine your identity (like the name or subject-alt-names) you or the determine capabilites of your cert (and private key) (like the basic constraints, KU, EKU, Cert Policies, name constraints extensions). Is it more clear now? Camilo -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: reduce default OCSP timeouts.
On 10/11/13 1:39 PM, Bob Clary wrote: On 10/11/2013 12:57 PM, Camilo Viecco wrote: Hello List I am planning to land a patch to reduce the default (soft-fail) OCSP network timeout values. Currently OCSP connections timeout after 10 seconds and my plan is to changed that to 3 seconds (hard fail will keep the current 10 second timeout value). With this change (according to telemetry) we will cover 95% of successful checks in desktop and 90% of fennec. (2 seconds is 90% of desktop 85% of fennec). Currently fennect cancelled connections are about 6% of connections. Any issues with this change? Thanks Camilo How will this play with high latency connections such as found on Satellite-based internet where ping times are 600-1000ms? Since fetching the OCSP response takes 2RTT (without closing the connection) a 3 second timeout would be sufficient for 1000ms RTT. But if you desire you can still enable strict ocsp responses and that will give you back the 10 second timeouts. Camilo /bc -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: reduce default OCSP timeouts.
On 10/11/13 1:58 PM, Eddy Nigg wrote: On 10/11/2013 11:50 PM, From Wan-Teh Chang: I would use a timeout of 5 seconds. 3 seconds seem a little short. I agree 10 seconds are too long. +1 Thanks Eddy/Wan Tech: 5 seconds seems too high for a fail open option, but let me ask you: what percent of checks are you comfortable with (given soft fail). Camilo -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Hello Brian I think this proposal has 3 sections. 1. Unifing SSL behavior on browsers. 2. Altering the criteria for cipher suite selection in Firefox (actually NSS) 3. removing certain cipher suites from the default firefox ciphersuite. On 1: I dont see the point, but I am not against. On 2: The proposal is not clear. I want an algorithmic definition. For example in nss we can see in sslenum.c : -strong ciphers before weaker - national ciphers before international - faster ciphers before slow ciphers. But your proposal it not clear. Here is my reverse engineering of the criteria to get to your list: 1. Message Authentication: MD5 last. rationale: security 2. Key exchange (round1): PFS before non-PFS suites rationale: privacy, goal stop supporting non-PFS suites. 3. Bulk encoding (round1): aes(all variations) before national ciphers before 3des before rc4 before des before export ciphers before null. rationale: security, aes is the most studied cipher both in implementation and theory. RC4 has shown weakness. reationale2 performance: 3des is slow and does not provide much security over the other ciphers. 4. Authentication (round1) : DSS last rationale: it is not really used, want to deprecate. 5. Key Exchange (round2): ECDH before DHE. rationale: ECDH allows negotiation form client. 6. Bulk encoding (round 2): 128 AES before 256 AES rationale: performance and minimal security gains. 7. Message Authentication: authenticated encryption (GCM) before SHA before SHA256 before sha384 a. AEAD before HMAC : performance b. sha ordering: performance 8. Authentication: RSA before ECDSA a. RSA before ECDSA : performance b. DSA last: not in use This criteria gets to your ordering proposal. What do you think of re-framing your list in a criteria like this? (note national ciphers could go in step 6 instead of step 3). On 3: I understand the issues with small packets so I agree we need to prune. On this regard: national ciphers: concur with Gerv need to talk but I am inclined to remove them (from the defaults, not from NSS). removal of null encoding and auth cipher suites: agreed. Keeping TLS_DHE_DSS_WITH_AES_128_CBC_SHA and the only DSS for compatibility: agreed Keeping TLS_RSA_WITH_3DES_EDE_CBC_SHA as the only 3DES for compatibility: agreed RC4 cipher agreed:removal agreed. Not adding any TLS 1.2 cipher that does not use PFS agreed. Not adding: TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256 Disagree I dont think a potential performance issue should prevent us from deploying that suite as there could be sha1 attacks that we dont know of. If we have enough space in the handshake I see no problem in including them. Removal seems like a premature optimization. Camilo On 8/15/13 10:15 AM, Chris Richardson wrote: 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: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 8/16/13 11:13 AM, Camilo Viecco wrote: Hello Brian I think this proposal has 3 sections. 1. Unifing SSL behavior on browsers. 2. Altering the criteria for cipher suite selection in Firefox (actually NSS) 3. removing certain cipher suites from the default firefox ciphersuite. On 1: I dont see the point, but I am not against. On 2: The proposal is not clear. I want an algorithmic definition. For example in nss we can see in sslenum.c : -strong ciphers before weaker - national ciphers before international - faster ciphers before slow ciphers. But your proposal it not clear. Here is my reverse engineering of the criteria to get to your list: 1. Message Authentication: MD5 last. rationale: security 2. Key exchange (round1): PFS before non-PFS suites rationale: privacy, goal stop supporting non-PFS suites. 3. Bulk encoding (round1): aes(all variations) before national ciphers before 3des before rc4 before des before export ciphers before null. rationale: security, aes is the most studied cipher both in implementation and theory. RC4 has shown weakness. reationale2 performance: 3des is slow and does not provide much security over the other ciphers. 4. Authentication (round1) : DSS last rationale: it is not really used, want to deprecate. 5. Key Exchange (round2): ECDH before DHE. ( And by ECDH I meant ECDHE rationale: ECDH allows negotiation form client. 6. Bulk encoding (round 2): 128 AES before 256 AES rationale: performance and minimal security gains. 7. Message Authentication: authenticated encryption (GCM) before SHA before SHA256 before sha384 a. AEAD before HMAC : performance b. sha ordering: performance 8. Authentication: RSA before ECDSA a. RSA before ECDSA : performance b. DSA last: not in use This criteria gets to your ordering proposal. What do you think of re-framing your list in a criteria like this? (note national ciphers could go in step 6 instead of step 3). On 3: I understand the issues with small packets so I agree we need to prune. On this regard: national ciphers: concur with Gerv need to talk but I am inclined to remove them (from the defaults, not from NSS). removal of null encoding and auth cipher suites: agreed. Keeping TLS_DHE_DSS_WITH_AES_128_CBC_SHA and the only DSS for compatibility: agreed Keeping TLS_RSA_WITH_3DES_EDE_CBC_SHA as the only 3DES for compatibility: agreed RC4 cipher agreed:removal agreed. Not adding any TLS 1.2 cipher that does not use PFS agreed. Not adding: TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256 Disagree I dont think a potential performance issue should prevent us from deploying that suite as there could be sha1 attacks that we dont know of. If we have enough space in the handshake I see no problem in including them. Removal seems like a premature optimization. Camilo On 8/15/13 10:15 AM, Chris Richardson wrote: 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
