Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 15/08/13 18:15, 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. Chris, Firefox already offers ECDHE-ECDSA ciphersuites, so I don't think Brian's plan would introduce any _new_ side effects relating to that OSX (10.8..10.8.3) bug. Are you suggesting that Firefox should drop support for all ECDHE-ECDSA ciphersuites? Or are you suggesting that NSS should implement the equivalent of that proposed OpenSSL patch, so that NSS-based TLS servers can avoid attempting to negotiate ECDHE-ECDSA with broken OSX clients? Or what? Should browsers drop support now for all TLS features that might possibly suffer broken implementations in the future? (For example, AGL would like to get rid of AES-GCM because it's hard to implement securely. See https://www.imperialviolet.org/2013/01/13/rwc03.html) [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 -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- 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 Fri, August 16, 2013 6:36 am, Rob Stradling wrote: On 15/08/13 18:15, 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. Chris, Firefox already offers ECDHE-ECDSA ciphersuites, so I don't think Brian's plan would introduce any _new_ side effects relating to that OSX (10.8..10.8.3) bug. I think the point was that fingerprinting the TLS handshake has some positive value, and is not inherently negative - as demonstrated by that OpenSSL patch. That's not to suggest that every UA shold report the UA string in the TLS handshake, but just pointing out that when mistakes (in implementations) happen, it's nice to be able to identify them and work around. Cheers, Ryan Are you suggesting that Firefox should drop support for all ECDHE-ECDSA ciphersuites? Or are you suggesting that NSS should implement the equivalent of that proposed OpenSSL patch, so that NSS-based TLS servers can avoid attempting to negotiate ECDHE-ECDSA with broken OSX clients? Or what? Should browsers drop support now for all TLS features that might possibly suffer broken implementations in the future? (For example, AGL would like to get rid of AES-GCM because it's hard to implement securely. See https://www.imperialviolet.org/2013/01/13/rwc03.html) [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 -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- 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
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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com 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. 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). Camilo, I think you reverse-engineered Brian's criteria correctly. The new criteria seem fine. I would prefer ECDSA over RSA for authentication. 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. The way HMAC-SHA1 uses SHA1 is much more complicated than the way public key signatures use SHA1. This is why SHA1 collision attacks usually don't affect the security of HMAC-SHA1. Wan-Teh -- 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 16/08/13 23:05, Wan-Teh Chang wrote: snip 8. Authentication: RSA before ECDSA a. RSA before ECDSA : performance b. DSA last: not in use snip ... I would prefer ECDSA over RSA for authentication. Wan-Teh, why do you think Firefox should specify a preference for ECDSA over RSA? If a webserver wants to prefer ECDSA over RSA, then it can override the browser-supplied cipher-suite order. e.g. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslhonorcipherorder -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- 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 Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@comodo.com wrote: Wan-Teh, why do you think Firefox should specify a preference for ECDSA over RSA? Because ECDSA is more secure than RSA, and ECC implementations will become faster over time. The ordering of RSA and ECDSA is really a symbolic gesture right now because they each require a certificate, and very few websites have both an RSA certificate and an ECDSA certificate. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
