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
