Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Friday, January 3, 2014 6:24:23 PM UTC+2, Julien Vehent wrote: According to http://www.modern.ie/ie6countdown: * 22.2% of China uses IE6 * 4.9% of users worlwide use IE6 I believe that our jobs, as security professionals, is to provide the best security to everyone. Not only to the people that have a better access to technology. I think it would be good to separate these four questions: 1) What ciphersuite list should Firefox use for initial TLS handshake? (Hopefully no RC4 ciphersuites on this list in the future--following IE11's lead.) 2) What ciphersuite list should Firefox use for a downgrade handshake? (Probably needs to include RC4 ciphersuites for some time.) 3) What ciphersuite list should Mozilla recommend to Mozilla servers that aren't on the Firefox download path and to third-party server admins? (Hopefully this list wouldn't be influenced by IE on XP--at least not after April.) 4) What ciphersuite list should Mozilla use for those servers that IE on XP needs to handshake with in order for the user to use IE on XP to download Firefox? It seems that the OP focused on #1, you are focusing on #4 and there are others who are focusing on #3. I think https://wiki.mozilla.org/Security/Server_Side_TLS would become better if it distinguished between #3 and #4, since the doc is read by third-party admins but Mozilla is a special case, because Mozilla needs to make it possible to download Firefox using IE on XP and, therefore, needs to use a worse config than what third parties could use for their servers. BTW, is there any progress in terms of getting the vendor that needs to connect to Mozilla's servers using Java 6 to upgrade? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Jan 5, 2014, at 4:27 PM, Kurt Roeckx k...@roeckx.be wrote: On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote: 3DES isn't broken. Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we recomend are at least at 128bit security. The document doesn't seem to say that it's trying to reach a 128 bit security level over the whole chain. It seems to be happy with 2048 bit RSA keys. They also provide 112 bit security. True, that's inconsistent. I'll put it to the TODO list. If you really want to go for 128 bit, you need to have the RSA keys of at least something in the order of 3072 bit. If 2048 is fine, 3DES is fine. Kurt ___ Ach mailing list a...@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/ach --- // L. Aaron Kaplan kap...@cert.at - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi! Sorry for being rather late in my reply; most of your questions/remarks are already answered. The guide is not backward compatible with all clients. We, at Mozilla, must maintain backward compatibility with even the oldest, most broken, clients on the internet, and this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4, and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could just remove these two ciphers, but it's not a realistic goal in the near future. True. I personally consider unsupported software depreciated and will not put effort in supporting it. In case you need to support WinXP and Java6 we discussed a workaround some months ago: you may simply use the lack of SNI support in those software stacks to provide a default virtual host with a weaker cipher set hinting the user to upgrade their clients/cryptostack/os/whatever. Java7, however, supports SNI -- therefor this will not work for Java7. Another possibility would be to filter access to certain services (login for example) based on a cipher white list: only users with strong ciphers are allowed to access the login page; the rest gets redirected to a different page. Both of those recommendations are way beyond the scope of our guide, I guess. And at least the second one is not trivial to get right... ;-) There is another aspect too: this cipher string is meant to protect secrets (passwords and the like) for at least some reasonable amount of time, so I see no way to offer support for Java6 or WinXP (at least with its default crypto stack). If I understood correctly you are trying to achieve some kind of opportunistic encryption where it does not matter that much how strong the crypto around the download really is: if that is the case, you may just enable 3DES and/or RC4 and you're fine off. But that case is different for two reasons: First you are a real sysadmin able to choose on your own (which is excellent btw.) and second there is a difference in secrets that need protection. I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. The intention of the cipher string is to support both: CAMELLIA and AES as ENISA recommends in their paper too. That it returns AES first is unfortunate and caused by OpenSSL: all the CAMELLIA suites in TLSv1.2 aren't implemented in OpenSSL, so e.g. no CAMELLIA+GCM is available and no CAMELLIA with SHA-2. The ordering of ciphers by putting SSLv3 (and TLSv1.0) at the end and prefering TLSv1.2 is obvious (see +SSLv3 in the cipher string). ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and makes the ciphersuite portable to systems that prefer ECDSA certicates (granted, it's not that many...). Yup. We disabled DSA because all our recommendations deal with RSA; adding DSA would need more research on best practices and the like around DSA. -- Adi signature.asc Description: Digital signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 03 Jan 2014, at 00:19, Aaron Zauner a...@azet.org wrote: After BREAK there was this huge outcry by “security professionals” to switch to RC4, I still think that was a dumb idea. Sorry. BREACH of course. Aaron signature.asc Description: Message signed with OpenPGP using GPGMail -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
ARGH! Third time’s a charm: BEAST. BREACH is CRIME related and has nothing to do with that. Aaron signature.asc Description: Message signed with OpenPGP using GPGMail -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi Kurt, On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I know that for AES people having been putting an effort in making this constant time. Having AES-NI clearly helps with this. I can't say the same for Camellia and so think it doesn't make sense to prefer it over AES. Yes. NSS/Firefox currently still has Camellia as first non-ECDHE and as result does use it for sites supporting it. But as far as I know it's the only browser supporting it, and the next version is going to prefer AES over Camellia all the time which resulted in it's usage going from about 5% to as good as 0%. Sadly, yes. Camellia is a good cipher, but with AES-NI it’s almost irrelevant to TLS traffic. There has also been talk about either disbaling it by default or even dropping support for it but that currently didn't happen yet. That’s a good point. We might want to review this decision. We generally do that during meet ups (are reported onto the ML) or on the mailing list. What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? Thanks, Aaron signature.asc Description: Message signed with OpenPGP using GPGMail -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 14-01-05 16:56, Aaron Zauner a...@azet.org wrote: On Sun, Jan 5, 2014 at 4:27 PM, Kurt Roeckx k...@roeckx.be wrote: On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote: 3DES isn't broken. Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we recomend are at least at 128bit security. The document doesn't seem to say that it's trying to reach a 128 bit security level over the whole chain. It seems to be happy with 2048 bit RSA keys. They also provide 112 bit security. If you really want to go for 128 bit, you need to have the RSA keys of at least something in the order of 3072 bit. If 2048 is fine, 3DES is fine. That is true, the issue being that some software and hardware platforms do not support RSA keys above 2048bit as of now. I mean - I do not really have an issue with discussing to put 3DES in there. We were a bit time restricted to do our research (i.e. we limited ourselves to certain ciphers) and since this is still in draft stage we're able to change things like that. Input from anyone else on the list? While there are certain uses for 3DES, e.g. backward-compatibility in cases where its really necessary, generally 3DES being EOL should be a red flag imho: no further research from the good guys will go into 3DES, since all the papers would be rejected with oh, that old crap, don't you have something interesting?. Otoh, this is a great situation for the bad guys. Also, since especially coming from the browser crowd efficiency seems to be a concern 3DES is worse than the alternatives like AES. Generally I would suggest keeping the current level of security (128 bit, except where maybe RSA doesn't work for some reasons) and maybe provide a hint like We don't recommend 3DES, but if you really really need it for old crap like Win XP or Java, add this: And if in the general case some old clients can't connect, so be it, maybe they'll take the hint and upgrade, fix their stuff, etc. Vendors will only fix stuff if enough users start complaining (for non-EOL products) and users will only update if stuff doesn't work. Ciao, Alexander Wuerstlein. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi Julien, I took the liberty to answer a few of your questions (in CC to dev-tech-crypto and ach). Others might want to add something as well: On 02 Jan 2014, at 18:09, Julien Vehent jul...@linuxwall.info wrote: Overall, I think this guide is great! The configuration examples are very useful. It's also good to have multiple TLS guides with different audiences, so I'm definitely glad to see more people take on the issue. Thank you. Why prefer DHE to ECDHE, when the former is 3 times slower than the later? There is a bit of a justification in 3.5: Since there is much discussion on the security of ECC, flawed settings might very well compromise the security of the entire system. I wish there was references to these discussions. My understanding of the state of the art of ECC is that P-256 is considered at least as secure as DH and RSA. Well, no. Bernstein and Lange have been auditing NIST/SECG and other standardized curves that are currently implemented in crypto libraries over the last years. They may be considered secure against the ECDLP (some) but other issues remain that caused us to prefer DHe over ECDHe. We’re aware of the performance implications - the paper in general tries to cope with best performance and backwards compatability, but not at the cost of security. I’m aware that this philosophy might differ to that of the Mozilla Security Team. Recent publications have prompted some change in mindset though and one cannot recommend a security guide that takes all factors into consideration at the potential cost of (side channel) attacks or downgrade attacks. Please take the time to read up on: - http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf - http://safecurves.cr.yp.to/ - http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters (There’s also interesting research to Koblitz curves in the reply by thomas pornin) They recommend AES-128 in 3.4. Keylengths, but publish a ciphersuite that prefers AES-256 (see below). This is probably just an oversight, the guide is still in Draft”. Our viewpoint was that if possible, take a stronger cipher. We’re aware that people might want to change this in their configuration if performance is paramount. We probably should discuss this again. The guide is not backward compatible with all clients. We, at Mozilla, must maintain backward compatibility with even the oldest, most broken, clients on the internet, and this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4, and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could just remove these two ciphers, but it's not a realistic goal in the near future. I personally think this is the wrong descision. I’m aware that you want to cater to as many clients as possible, but you also want to ship a solid and secure product. What people see and care about when they surf from XP machines using RC4 or 3DES is this nice green padlock in the browser bar. What they actually get as security are ciphers that have been considered insecure in academia for now over 15 years. Same goes for the recommendation to use DH parameters 1024 bits. We tried using a 2048 bits parameter a few months back. We first noticed a big spike in CPU usage, caused by the largest exponentiation, but that was still acceptable. What forced the rollback is the long list of java 6 clients that broke, because they don't accept DH keys 1024 bits. Until all of these clients get fixed, DH params will be limited to 1024 bits. As far as I know stronger DH params are supported by the Java Crypto Extensions package. That said it’s usually not deployed anywhere. We’re aware of the issue but using DH parameters of 1024 bits only can provide security that is slightly less than 1024bit RSA which can certainly be factored by large agencies. - It takes you about 48hours to factor 512bit RSA keys in EC2: http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf - The largest Key factored by public research (in a small university setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006 We hope that Java will adopt a reasonable security policy in the future, although I’m personally not conviced that they will. I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. We hope the IETF TLS-WG will chose to adopt the proposal by Adam Langley of Google to include the ChaCha20 stream cipher
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi Kurt, That is true, the issue being that some software and hardware platforms do not support RSA keys above 2048bit as of now. I mean - I do not really have an issue with discussing to put 3DES in there. We were a bit time restricted to do our research (i.e. we limited ourselves to certain ciphers) and since this is still in draft stage we're able to change things like that. Input from anyone else on the list? Thanks, Aaron On Sun, Jan 5, 2014 at 4:27 PM, Kurt Roeckx k...@roeckx.be wrote: On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote: 3DES isn't broken. Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we recomend are at least at 128bit security. The document doesn't seem to say that it's trying to reach a 128 bit security level over the whole chain. It seems to be happy with 2048 bit RSA keys. They also provide 112 bit security. If you really want to go for 128 bit, you need to have the RSA keys of at least something in the order of 3072 bit. If 2048 is fine, 3DES is fine. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote: 3DES isn't broken. Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we recomend are at least at 128bit security. The document doesn't seem to say that it's trying to reach a 128 bit security level over the whole chain. It seems to be happy with 2048 bit RSA keys. They also provide 112 bit security. If you really want to go for 128 bit, you need to have the RSA keys of at least something in the order of 3072 bit. If 2048 is fine, 3DES is fine. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 5/01/14 18:27 PM, Kurt Roeckx wrote: On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote: 3DES isn't broken. Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we recomend are at least at 128bit security. The document doesn't seem to say that it's trying to reach a 128 bit security level over the whole chain. It seems to be happy with 2048 bit RSA keys. They also provide 112 bit security. As others have mentioned, these aren't quite comparable. 3DES has an 8 byte block, which gives its own problems. AES is a stronger more modern algorithm. Key length isn't an exact proxy for security. Also, the setting of the RSA key is more driven by software capabilities and CA's capabilities compliances with mountains of documents than anything else. Rather chalk cheese, you can't just wind up the RSA key size by setting a param in config, more's the pity. iang If you really want to go for 128 bit, you need to have the RSA keys of at least something in the order of 3072 bit. If 2048 is fine, 3DES is fine. Kurt ___ Ach mailing list a...@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/ach -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Julien Vehent jul...@linuxwall.info writes: I would argue that our documents target server configurations, where AES-NI is now a standard. It is not. Many sites run on virtuals, often using kvm. And most kvm sites provide a QEMU Virtual CPU which only supports sse2. And even without kvm, there is still a /lot/ of pre-aes-ni hardware in use. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi Julian, On 4/01/14 00:04 AM, Julien Vehent wrote: On 2014-01-03 12:58, ianG wrote: Right, Windows XP. Which is end of life. Microsoft killing support for a product isn't the same thing as people throwing away their computers. Or, are you implying that because microsoft is ending the life of XP, we should feel comfortable disconnecting these people from the internet? I'm not sure what they did to deserve that, except spending thousands of dollars on a computer years ago. It depends on your mission. Here, we're seeking better crypto. At Mozilla, it's clear that you're seeking access to the web for all. These are very different missions. The mission drives all. It's pretty clear that users of XP, etc, will not be using better crypto. They aren't now, they won't as long as they keep using XP. They are already outside our chosen domain, nothing we can do will bring them back into it. Only they can act. Hmmm.. Are the Chinese blocked from stronger crypto? According to http://www.modern.ie/ie6countdown: * 22.2% of China uses IE6 * 4.9% of users worlwide use IE6 Thanks for that! More end of life. And DJB says it's worse, we've retrograded to about 50% RC4 usage. Apples and Oranges. Some websites owners prefer RC4 for various reasons, but it's different from what clients can actually negotiate. Even if all website owners update their ciphersuite tomorrow, that won't replace the millions of computers than are stuck on RC4 and 3DES. Right. It's apples and oranges and pears and grapefruits and grapes and carrots and turnips too. If your mission is to keep these people on the web, then yes, you need to keep RC4 and 3DES alive. I'm not sure what, in my message, triggered such a strong reaction. As I said in a previous email: Oh, my fault, definitely: Mozilla's mission isn't necessarily workable or adoptable outside Mozilla, so we have to be careful to understand when and how it causes tensions. 1. I think it's great to have two guides with divergent points of view. I'm mostly interested in discussing design choices, because these discussions are useful. I'm not interested in convincing the ACH group that one recommendation is better than the other, since it completely depends on the context. If anyone has a secret sauce to replace all of the ancient software out there, with newer one that support TLS1.2, OCSP Stapling and so on, I'm 200% up for it. There isn't any secret sauce, algorithm agility totally failed as a solution. Hard decisions have to be made. People will suffer. Or it gets worse. To put a date on it, everything changed in 2011. What worked before is not necessarily going to work any more. In the meantime, it's important that users can reach mozilla.org from IE6, so that they can install Firefox and enjoy stronger security. If you mean, stronger security than say HTTP, I'm all for it. My writings on Mozilla lists to this end are voluminous and drowning... But it's a long long debate, and once we drag security into it, it gets messy. Frankly, Mozilla is best off doing what it does: getting web to users, and following standards. I'm an avid user of Firefox and Tbird, myself, I don't want these tools to go away. If there's a message for Mozilla here, it might be this: those old algorithms may become less useful sooner than we'd like... iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2/01/14 20:09 PM, Julien Vehent wrote: I wish there was references to these discussions. The problem with any references to rationale is that it often goes into arguable and unending discussions. There's a certain value in being quite curt about the recommendation, and readers can take it or leave it. Obviously, the recommendations can be wrong, but they are valuable if they are mostly right and easy to follow. And every name stakes their rep to it. The document is already huge... which makes it hard to follow... My understanding of the state of the art of ECC is that P-256 is considered at least as secure as DH and RSA. The general issue is all of the standardised EC curves are under a cloud, in part because of the DUAL_EC saga, and in part because DJB Tanje Lange have heavily criticised the standard curves. Have a look at their table at http://safecurves.cr.yp.to/ there's definitely a problem with all prior work. How much is this overdone? I don't think it is as important as the RC4 issue. We know RC4 can be cracked in some standard daily amounts, 16M and beyond. We don't know that about ECC nor 3DES. Coming back to public key choice, it is now an open question: Do we recommend just RSA for now and wait until the new curves come on line? Or stick with ECC as it is now available, because fears are overblown? I don't know the answer to that one, but framing the question is often half the battle. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-02 18:59, ianG wrote: On 3/01/14 01:06 AM, Julien Vehent wrote: 3DES isn't broken. No, but it is end of life. 112bit security for the 2key variant, and an 8 byte block makes it just old. If you've got AES there, use it. Who hasn't got it? See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses Internet Explorer uses the cryptographic library “schannel”, which is OS dependent. schannel supports AES in Windows Vista, but not in Windows XP. RC4 is broken, but I am yet to see a practical attack that doesn't require gigabits of traffic. What is a real concern is RC4. Anything done to move away from that has to be a good thing. The recent talk by DJB has some real fun descriptions of just how crappy it is becoming. http://financialcryptography.com/mt/archives/001461.html The way I read it, trouble starts at 2^24, that's 16M. By the time you get to 2^30 or 1G it's all over... Caveat -- I'm working from the graphs described from p49 of the talk, I don't pretend to understand them other than what the pictures say. Again, this is the tradeoff between what academia thinks is secure, and the level of security users need. It's more important for us to allow Chinese users to download Firefox, than it is to disable RC4 (that westerners almost never use anyway). Hmmm.. Are the Chinese blocked from stronger crypto? According to http://www.modern.ie/ie6countdown: * 22.2% of China uses IE6 * 4.9% of users worlwide use IE6 I believe that our jobs, as security professionals, is to provide the best security to everyone. Not only to the people that have a better access to technology. This is consistent with Mozilla's mission. So we won't disable old crypto algorithms because the security community admits that they are bad. We have to live with them. Again, site owners are free to make their own decisions. This isn't an unbreakable rule. At Mozilla, for example, the persona websites are unusable with old browsers anyway, so it makes sense to enable stronger TLS on that one specifically. Same goes for the recommendation to use DH parameters 1024 bits. We tried using a 2048 bits parameter a few months back. We first noticed a big spike in CPU usage, caused by the largest exponentiation, but that was still acceptable. What forced the rollback is the long list of java 6 clients that broke, because they don't accept DH keys 1024 bits. Java 6 is covered in mud all over, crypto wise. Maybe time for some nasty words to start circulating. Until all of these clients get fixed, DH params will be limited to 1024 bits. As far as I know stronger DH params are supported by the Java Crypto Extensions package. That said it’s usually not deployed anywhere. We’re aware of the issue but using DH parameters of 1024 bits only can provide security that is slightly less than 1024bit RSA which can certainly be factored by large agencies. - It takes you about 48hours to factor 512bit RSA keys in EC2: http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf - The largest Key factored by public research (in a small university setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006 We hope that Java will adopt a reasonable security policy in the future, although I’m personally not conviced that they will. Problem here is that it isn't so much 'Java' it's more the platforms. Android is stuck on Java 6, and the JCE choices aren't even that modern. http://financialcryptography.com/mt/archives/001450.html Mac OSX has now bailed from Java directly, so one gets it from Oracle/sun directly, which means Java 7. For us, it's a choice between DHE with 1024, or no DHE at all. We will not block a subgroup of users because they don't support larger keys. And I suspect no business ever will. So, on DHE vs !DHE, here's the rationale: RSA key rotations happen very rarely in hosting environments. Except when the CA requires it, it's not uncommon to see private keys that are several years old. Keys also move very easily, end up in people's mailboxes or shared folders, or get stored in cloud providers that don't zero their disks after use. From an operational perspective, the risk of leaking a RSA private key is many times higher than the risk of factoring a DHE key exchange. Even if this key exchange uses half the key size of the RSA key. If an organization wants to spy on Mozilla's DHE traffic, they need to factor *every single key exchange*. On a normal day, that's hundreds of thousands of them. I'm quite certain that the biggest security agencies have clusters than can factor a 1024 DHE key within minutes, but it's still a lot harder and more targeted than factoring one single 2048 RSA key that is used for 5 years. For this reason, we recommend DHE with 1024 bits parameters, and RSA 2048 keys for authentication. I agree with that. I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 3/01/14 19:24 PM, Julien Vehent wrote: On 2014-01-02 18:59, ianG wrote: On 3/01/14 01:06 AM, Julien Vehent wrote: 3DES isn't broken. No, but it is end of life. 112bit security for the 2key variant, and an 8 byte block makes it just old. If you've got AES there, use it. Who hasn't got it? See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses Internet Explorer uses the cryptographic library “schannel”, which is OS dependent. schannel supports AES in Windows Vista, but not in Windows XP. Right, Windows XP. Which is end of life. Hmmm.. Are the Chinese blocked from stronger crypto? According to http://www.modern.ie/ie6countdown: * 22.2% of China uses IE6 * 4.9% of users worlwide use IE6 Thanks for that! More end of life. And DJB says it's worse, we've retrograded to about 50% RC4 usage. I believe that our jobs, as security professionals, is to provide the best security to everyone. That is mozilla's mission. It provides its products to everyone. Which naturally means it cannot and does not provide the 'best security' to every person, rather it provides the best 'security for everyone'. Different story -- one moves security up, at the expense of users, the other keeps users happy, but puts security on a race to the bottom. Not only to the people that have a better access to technology. This is consistent with Mozilla's mission. Absolutely! I'm well familiar of how the monolith of Mozilla's mission casts a shadow over security. BetterCrypto however is seeking ... *better crypto*. And that is a different goal. Different users, different tradeoffs. Where the two groups part company is on bad crypto. If IE6 and XP users have bad crypto, then BetterCrypto is not for them. So we won't disable old crypto algorithms because the security community admits that they are bad. We have to live with them. Sure. And to some extent I don't disagree -- K6 speaks to ease of use and availability; it is the number one, dominating law for security. But the enemy of cryptography is time; what was secure then is not now. It doesn't take much to deal with it, but unfortunately the powers that be SSL have fiddled around adding more and not chopping away. Always because someone wants to keep it around. This is a rock and a hard place. The rock of upgrading has met the hard place of legacy users. Where this goes from here is tension: BetterCrypto and groups like it will continue to deprecate those ciphers. Users will start to suffer. Users will complain. Mozilla and browsers and so forth will cop the brunt of the suffering. Very unfair. But meanwhile the fix is in. And if there is one thing we do know, the juggernaut of SSL/IETF/PKIX/CABForum/OpenSSL/NSS/NIST/Sun/ and a dozen other acronyms I've forgotten ... are not going to push on this front. They are going to do what they always do: act as if every old cipher is like a limb, squealing and moaning at the thought that it is going to be cut off, all the while salivating at the chance to add another cipher suite, more, moar! :) prove me wrong! See how long it takes to get any of those groups of power to announce an end of life for RC4. Or 3DES. Bloody android is still using MD5, last I heard... BetterCrypto *has to lead* because everyone else is following each other in a big circle. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-03 12:58, ianG wrote: On 3/01/14 19:24 PM, Julien Vehent wrote: On 2014-01-02 18:59, ianG wrote: On 3/01/14 01:06 AM, Julien Vehent wrote: 3DES isn't broken. No, but it is end of life. 112bit security for the 2key variant, and an 8 byte block makes it just old. If you've got AES there, use it. Who hasn't got it? See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses Internet Explorer uses the cryptographic library “schannel”, which is OS dependent. schannel supports AES in Windows Vista, but not in Windows XP. Right, Windows XP. Which is end of life. Microsoft killing support for a product isn't the same thing as people throwing away their computers. Or, are you implying that because microsoft is ending the life of XP, we should feel comfortable disconnecting these people from the internet? I'm not sure what they did to deserve that, except spending thousands of dollars on a computer years ago. Hmmm.. Are the Chinese blocked from stronger crypto? According to http://www.modern.ie/ie6countdown: * 22.2% of China uses IE6 * 4.9% of users worlwide use IE6 Thanks for that! More end of life. And DJB says it's worse, we've retrograded to about 50% RC4 usage. Apples and Oranges. Some websites owners prefer RC4 for various reasons, but it's different from what clients can actually negotiate. Even if all website owners update their ciphersuite tomorrow, that won't replace the millions of computers than are stuck on RC4 and 3DES. I believe that our jobs, as security professionals, is to provide the best security to everyone. That is mozilla's mission. It provides its products to everyone. Which naturally means it cannot and does not provide the 'best security' to every person, rather it provides the best 'security for everyone'. Different story -- one moves security up, at the expense of users, the other keeps users happy, but puts security on a race to the bottom. Not only to the people that have a better access to technology. This is consistent with Mozilla's mission. Absolutely! I'm well familiar of how the monolith of Mozilla's mission casts a shadow over security. BetterCrypto however is seeking ... *better crypto*. And that is a different goal. Different users, different tradeoffs. Where the two groups part company is on bad crypto. If IE6 and XP users have bad crypto, then BetterCrypto is not for them. So we won't disable old crypto algorithms because the security community admits that they are bad. We have to live with them. Sure. And to some extent I don't disagree -- K6 speaks to ease of use and availability; it is the number one, dominating law for security. But the enemy of cryptography is time; what was secure then is not now. It doesn't take much to deal with it, but unfortunately the powers that be SSL have fiddled around adding more and not chopping away. Always because someone wants to keep it around. This is a rock and a hard place. The rock of upgrading has met the hard place of legacy users. Where this goes from here is tension: BetterCrypto and groups like it will continue to deprecate those ciphers. Users will start to suffer. Users will complain. Mozilla and browsers and so forth will cop the brunt of the suffering. Very unfair. But meanwhile the fix is in. And if there is one thing we do know, the juggernaut of SSL/IETF/PKIX/CABForum/OpenSSL/NSS/NIST/Sun/ and a dozen other acronyms I've forgotten ... are not going to push on this front. They are going to do what they always do: act as if every old cipher is like a limb, squealing and moaning at the thought that it is going to be cut off, all the while salivating at the chance to add another cipher suite, more, moar! :) prove me wrong! See how long it takes to get any of those groups of power to announce an end of life for RC4. Or 3DES. Bloody android is still using MD5, last I heard... BetterCrypto *has to lead* because everyone else is following each other in a big circle. iang I'm not sure what, in my message, triggered such a strong reaction. As I said in a previous email: 1. I think it's great to have two guides with divergent points of view. I'm mostly interested in discussing design choices, because these discussions are useful. I'm not interested in convincing the ACH group that one recommendation is better than the other, since it completely depends on the context. If anyone has a secret sauce to replace all of the ancient software out there, with newer one that support TLS1.2, OCSP Stapling and so on, I'm 200% up for it. In the meantime, it's important that users can reach mozilla.org from IE6, so that they can install Firefox and enjoy stronger security. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 1/3/2014 2:04 PM, Julien Vehent wrote: On 2014-01-03 12:58, ianG wrote: On 3/01/14 19:24 PM, Julien Vehent wrote: On 2014-01-02 18:59, ianG wrote: On 3/01/14 01:06 AM, Julien Vehent wrote: 3DES isn't broken. No, but it is end of life. 112bit security for the 2key variant, and an 8 byte block makes it just old. If you've got AES there, use it. Who hasn't got it? See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses Internet Explorer uses the cryptographic library “schannel”, which is OS dependent. schannel supports AES in Windows Vista, but not in Windows XP. Right, Windows XP. Which is end of life. Microsoft killing support for a product isn't the same thing as people throwing away their computers. Or, are you implying that because microsoft is ending the life of XP, we should feel comfortable disconnecting these people from the internet? I'm not sure what they did to deserve that, except spending thousands of dollars on a computer years ago. Hmmm.. Are the Chinese blocked from stronger crypto? According to http://www.modern.ie/ie6countdown: * 22.2% of China uses IE6 * 4.9% of users worlwide use IE6 Thanks for that! More end of life. And DJB says it's worse, we've retrograded to about 50% RC4 usage. Apples and Oranges. Some websites owners prefer RC4 for various reasons, but it's different from what clients can actually negotiate. Even if all website owners update their ciphersuite tomorrow, that won't replace the millions of computers than are stuck on RC4 and 3DES. I believe that our jobs, as security professionals, is to provide the best security to everyone. That is mozilla's mission. It provides its products to everyone. Which naturally means it cannot and does not provide the 'best security' to every person, rather it provides the best 'security for everyone'. Different story -- one moves security up, at the expense of users, the other keeps users happy, but puts security on a race to the bottom. Not only to the people that have a better access to technology. This is consistent with Mozilla's mission. Absolutely! I'm well familiar of how the monolith of Mozilla's mission casts a shadow over security. BetterCrypto however is seeking ... *better crypto*. And that is a different goal. Different users, different tradeoffs. Where the two groups part company is on bad crypto. If IE6 and XP users have bad crypto, then BetterCrypto is not for them. So we won't disable old crypto algorithms because the security community admits that they are bad. We have to live with them. Sure. And to some extent I don't disagree -- K6 speaks to ease of use and availability; it is the number one, dominating law for security. But the enemy of cryptography is time; what was secure then is not now. It doesn't take much to deal with it, but unfortunately the powers that be SSL have fiddled around adding more and not chopping away. Always because someone wants to keep it around. This is a rock and a hard place. The rock of upgrading has met the hard place of legacy users. Where this goes from here is tension: BetterCrypto and groups like it will continue to deprecate those ciphers. Users will start to suffer. Users will complain. Mozilla and browsers and so forth will cop the brunt of the suffering. Very unfair. But meanwhile the fix is in. And if there is one thing we do know, the juggernaut of SSL/IETF/PKIX/CABForum/OpenSSL/NSS/NIST/Sun/ and a dozen other acronyms I've forgotten ... are not going to push on this front. They are going to do what they always do: act as if every old cipher is like a limb, squealing and moaning at the thought that it is going to be cut off, all the while salivating at the chance to add another cipher suite, more, moar! :) prove me wrong! See how long it takes to get any of those groups of power to announce an end of life for RC4. Or 3DES. Bloody android is still using MD5, last I heard... BetterCrypto *has to lead* because everyone else is following each other in a big circle. iang I'm not sure what, in my message, triggered such a strong reaction. As I said in a previous email: 1. I think it's great to have two guides with divergent points of view. I'm mostly interested in discussing design choices, because these discussions are useful. I'm not interested in convincing the ACH group that one recommendation is better than the other, since it completely depends on the context. If anyone has a secret sauce to replace all of the ancient software out there, with newer one that support TLS1.2, OCSP Stapling and so on, I'm 200% up for it. In the meantime, it's important that users can reach mozilla.org from IE6, so that they can install Firefox and enjoy stronger security. - Julien If I may weigh in, one could certainly argue that there isn't any benefit in allowing these people to believe that their
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-03 16:09, Falcon Darkstar Momot wrote: If I may weigh in, one could certainly argue that there isn't any benefit in allowing these people to believe that their HTTPS connections are actually secure when they're using ciphers that we know to be broken (how much we know them to be broken is certainly up for debate). Even with RC4 or 3DES, that HTTPS icon still tells a user that their abusive relative can't read their emails on the house's proxy. What we, security professional, define as secure is widely different from what the average user wants or needs. People can still go to whatever site they want even if they can't use HTTPS, as long as the site is available over HTTP. What if the NSA could break all crypto in the world within seconds? Would we accept to type our passwords and emails over HTTP then? I suspect not. I wouldn't bother actually dropping support for a cipher suite until it can be trivially broken, though, as that is the point at which it has no value. Anything else is excessively heavyhanded. --FalconK - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I know that for AES people having been putting an effort in making this constant time. Having AES-NI clearly helps with this. I can't say the same for Camellia and so think it doesn't make sense to prefer it over AES. NSS/Firefox currently still has Camellia as first non-ECDHE and as result does use it for sites supporting it. But as far as I know it's the only browser supporting it, and the next version is going to prefer AES over Camellia all the time which resulted in it's usage going from about 5% to as good as 0%. There has also been talk about either disbaling it by default or even dropping support for it but that currently didn't happen yet. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 02, 2014 at 10:10:49PM +0100, Aaron Zauner wrote: What's the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? Not being part of the mozilla team myself, I at least have the impression that they want it. You might want to look at this old version: https://briansmith.org/browser-ciphersuites-01.html Lots has been discussed and changed since that, but it at least mentions it. Google is also working on getting it into NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=917571 Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi Aaron, On 2014-01-02 16:10, Aaron Zauner wrote: Hi Kurt, On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I would argue that our documents target server configurations, where AES-NI is now a standard. What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? There are 5 security teams at Mozilla, so Mozilla Sec Team is a very large group. I think we all want a new stream cipher in TLS to replace RC4. But that's going to take years, and won't help the millions of people who don't replace their software that often. From an Operations Security point of view, the question is: how do we provide the best security possible, with the cards we currently have in our hands, and without discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the short term. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Hi Aaron, Two things I'd like to mention before I reply: 1. I think it's great to have two guides with divergent points of view. I'm mostly interested in discussing design choices, because these discussions are useful. I'm not interested in convincing the ACH group that one recommendation is better than the other, since it completely depends on the context. 2. My experience as a web hosting engineer, and sysadmin, has convinced me that building security recommendations on what academia thinks alone is very dangerous. Security doesn't live in a bubble. It depends on people and systems. It must protect an activity, but never ever block it entirely. That being said, I put my comments below. On 2014-01-02 15:33, Aaron Zauner wrote: On 02 Jan 2014, at 18:09, Julien Vehent jul...@linuxwall.info wrote: Why prefer DHE to ECDHE, when the former is 3 times slower than the later? There is a bit of a justification in 3.5: Since there is much discussion on the security of ECC, flawed settings might very well compromise the security of the entire system. I wish there was references to these discussions. My understanding of the state of the art of ECC is that P-256 is considered at least as secure as DH and RSA. Well, no. Bernstein and Lange have been auditing NIST/SECG and other standardized curves that are currently implemented in crypto libraries over the last years. They may be considered secure against the ECDLP (some) but other issues remain that caused us to prefer DHe over ECDHe. We’re aware of the performance implications - the paper in general tries to cope with best performance and backwards compatability, but not at the cost of security. I’m aware that this philosophy might differ to that of the Mozilla Security Team. Recent publications have prompted some change in mindset though and one cannot recommend a security guide that takes all factors into consideration at the potential cost of (side channel) attacks or downgrade attacks. Please take the time to read up on: - http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf - http://safecurves.cr.yp.to/ - http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters (There’s also interesting research to Koblitz curves in the reply by thomas pornin) I will bail here. My understanding of the mathematics of ECC isn't sufficient to make a strong decisions. Others at Mozilla, Google and major organizations have decided to implement ECC, and we trust their decision. From my end, the decision to prefer ECC to DHE in Mozilla's guidelines is performance oriented. They recommend AES-128 in 3.4. Keylengths, but publish a ciphersuite that prefers AES-256 (see below). This is probably just an oversight, the guide is still in Draft”. Our viewpoint was that if possible, take a stronger cipher. We’re aware that people might want to change this in their configuration if performance is paramount. We probably should discuss this again. Aside from performance, timing attacks are apparently easier in AES-256. https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ The guide is not backward compatible with all clients. We, at Mozilla, must maintain backward compatibility with even the oldest, most broken, clients on the internet, and this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4, and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could just remove these two ciphers, but it's not a realistic goal in the near future. I personally think this is the wrong descision. I’m aware that you want to cater to as many clients as possible, but you also want to ship a solid and secure product. What people see and care about when they surf from XP machines using RC4 or 3DES is this nice green padlock in the browser bar. What they actually get as security are ciphers that have been considered insecure in academia for now over 15 years. 3DES isn't broken. RC4 is broken, but I am yet to see a practical attack that doesn't require gigabits of traffic. Again, this is the tradeoff between what academia thinks is secure, and the level of security users need. It's more important for us to allow Chinese users to download Firefox, than it is to disable RC4 (that westerners almost never use anyway). Same goes for the recommendation to use DH parameters 1024 bits. We tried using a 2048 bits parameter a few months back. We first noticed a big spike in CPU usage, caused by the largest exponentiation, but that was still acceptable. What forced the rollback is the long list of java 6 clients that broke, because they don't accept DH keys 1024 bits. Until all of these clients get fixed, DH params will be limited to 1024 bits. As far as I know stronger DH params are supported by the Java Crypto Extensions package. That said it’s usually not deployed anywhere. We’re aware of the issue
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote: Hi Aaron, On 2014-01-02 16:10, Aaron Zauner wrote: Hi Kurt, On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I would argue that our documents target server configurations, where AES-NI is now a standard. I would have to disagree here. The two largest users of NSS, by *any* measure, are Firefox and Chromium, both of which use it as a client. Further, the notion of server configurations is further muddied by efforts such as WebRTC, which sees a traditional client (eg: heterogeneous configurations and architectures) acting as both a DTLS client and a DTLS server. NSS in server mode is so full of sharp edges and so few code examples that I'd strongly discourage it being used as the reference for what NSS SHOULD do. Whatâs the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? There are 5 security teams at Mozilla, so Mozilla Sec Team is a very large group. I think we all want a new stream cipher in TLS to replace RC4. But that's going to take years, and won't help the millions of people who don't replace their software that often. Really? If anything, Firefox and Chromium have shown that new changes can be deployed on the order of weeks-to-months, and with server opt-in (such as NPN/ALPN), the majority of *users* traffic can be protected or enhanced within a few weeks-to-months after. Google already has deployed experimental support, for example. Likewise, the adoption of SPDY - within Firefox and within a number of significant web properties - show that it's significantly quicker than it used to be to protect users. You're correct that there's going to be a long-tail of sites that don't update, sure, but rapid deployment is certainly an increasing possibility for the majority of users. From an Operations Security point of view, the question is: how do we provide the best security possible, with the cards we currently have in our hands, and without discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the short term. - Julien I strongly, vehemently disagree with that conclusion. Solutions like ChaCha20/Poly1305 are able to reach a broad spectrum of users near immediately and ubiquitously, providing meaningful security and speed improvements to users. If the idea is that no solution is a good solution until it's a ubiquitous solution, well, that's just silly and not reflective of the world we live in at all. -- 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: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-02 17:12, Ryan Sleevi wrote: On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote: Hi Aaron, On 2014-01-02 16:10, Aaron Zauner wrote: Hi Kurt, On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I would argue that our documents target server configurations, where AES-NI is now a standard. I would have to disagree here. The two largest users of NSS, by *any* measure, are Firefox and Chromium, both of which use it as a client. Further, the notion of server configurations is further muddied by efforts such as WebRTC, which sees a traditional client (eg: heterogeneous configurations and architectures) acting as both a DTLS client and a DTLS server. NSS in server mode is so full of sharp edges and so few code examples that I'd strongly discourage it being used as the reference for what NSS SHOULD do. Sorry for the confusion. By our documents, I meant: * https://wiki.mozilla.org/Security/Server_Side_TLS * https://bettercrypto.org/ And not NSS in client mode. Your point about WebRTC making the client a server is interesting though. Which ciphers preferences will the server use ? What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? There are 5 security teams at Mozilla, so Mozilla Sec Team is a very large group. I think we all want a new stream cipher in TLS to replace RC4. But that's going to take years, and won't help the millions of people who don't replace their software that often. Really? If anything, Firefox and Chromium have shown that new changes can be deployed on the order of weeks-to-months, and with server opt-in (such as NPN/ALPN), the majority of *users* traffic can be protected or enhanced within a few weeks-to-months after. Google already has deployed experimental support, for example. Likewise, the adoption of SPDY - within Firefox and within a number of significant web properties - show that it's significantly quicker than it used to be to protect users. You're correct that there's going to be a long-tail of sites that don't update, sure, but rapid deployment is certainly an increasing possibility for the majority of users. There is the case of old clients that don't upgrade, and the case of servers. The reality on the server side isn't that bright, I'm afraid. Upgrading server components is still slow and difficult. I've been trying to find commercial systems that support the full blend of TLS features, and failed. Chances are that even if new ciphers make it into TLS1.3, they won't be widely deployed in any production environment for another 3 to 5 years. After all, TLS 1.2 was standardized in 2008, and we're just starting to see it. From an Operations Security point of view, the question is: how do we provide the best security possible, with the cards we currently have in our hands, and without discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the short term. - Julien I strongly, vehemently disagree with that conclusion. Solutions like ChaCha20/Poly1305 are able to reach a broad spectrum of users near immediately and ubiquitously, providing meaningful security and speed improvements to users. If the idea is that no solution is a good solution until it's a ubiquitous solution, well, that's just silly and not reflective of the world we live in at all. That is not what I meant. I simply wanted to point out that, on the operational side, changes and improvements are *a lot* slower to propagate. Even if ChaCha2020/Poly1305 are deployed in Firefox and Chrome tomorrow, we won't have them on the server side for a while. And when we do, there will still be a lot of users who don't use it. Look at the percentage of users who negotiate ECDHE with AES-GCM, for example. Don't get me wrong: it's a critical improvement to make. But in the meantime, we still need to find the best security trade offs for the remaining 80%. And, sadly, for some people, that means using RC4 or 3DES. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-02 17:12, Ryan Sleevi wrote: On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote: Hi Aaron, On 2014-01-02 16:10, Aaron Zauner wrote: Hi Kurt, On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I would argue that our documents target server configurations, where AES-NI is now a standard. I would have to disagree here. The two largest users of NSS, by *any* measure, are Firefox and Chromium, both of which use it as a client. Further, the notion of server configurations is further muddied by efforts such as WebRTC, which sees a traditional client (eg: heterogeneous configurations and architectures) acting as both a DTLS client and a DTLS server. NSS in server mode is so full of sharp edges and so few code examples that I'd strongly discourage it being used as the reference for what NSS SHOULD do. Sorry for the confusion. By our documents, I meant: * https://wiki.mozilla.org/Security/Server_Side_TLS * https://bettercrypto.org/ And not NSS in client mode. Your point about WebRTC making the client a server is interesting though. Which ciphers preferences will the server use ? What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? There are 5 security teams at Mozilla, so Mozilla Sec Team is a very large group. I think we all want a new stream cipher in TLS to replace RC4. But that's going to take years, and won't help the millions of people who don't replace their software that often. Really? If anything, Firefox and Chromium have shown that new changes can be deployed on the order of weeks-to-months, and with server opt-in (such as NPN/ALPN), the majority of *users* traffic can be protected or enhanced within a few weeks-to-months after. Google already has deployed experimental support, for example. Likewise, the adoption of SPDY - within Firefox and within a number of significant web properties - show that it's significantly quicker than it used to be to protect users. You're correct that there's going to be a long-tail of sites that don't update, sure, but rapid deployment is certainly an increasing possibility for the majority of users. There is the case of old clients that don't upgrade, and the case of servers. The reality on the server side isn't that bright, I'm afraid. Upgrading server components is still slow and difficult. I've been trying to find commercial systems that support the full blend of TLS features, and failed. Chances are that even if new ciphers make it into TLS1.3, they won't be widely deployed in any production environment for another 3 to 5 years. After all, TLS 1.2 was standardized in 2008, and we're just starting to see it. From an Operations Security point of view, the question is: how do we provide the best security possible, with the cards we currently have in our hands, and without discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the short term. - Julien I strongly, vehemently disagree with that conclusion. Solutions like ChaCha20/Poly1305 are able to reach a broad spectrum of users near immediately and ubiquitously, providing meaningful security and speed improvements to users. If the idea is that no solution is a good solution until it's a ubiquitous solution, well, that's just silly and not reflective of the world we live in at all. That is not what I meant. I simply wanted to point out that, on the operational side, changes and improvements are *a lot* slower to propagate. Even if ChaCha2020/Poly1305 are deployed in Firefox and Chrome tomorrow, we won't have them on the server side for a while. And when we do, there will still be a lot of users who don't use it. Look at the percentage of users who negotiate ECDHE with AES-GCM, for example. Don't get me wrong: it's a critical improvement to make. But in the meantime, we still need to find the best security trade offs for the remaining 80%. And, sadly, for some people, that means using RC4 or 3DES. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 02, 2014 at 02:12:47PM -0800, Ryan Sleevi wrote: What's the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? There are 5 security teams at Mozilla, so Mozilla Sec Team is a very large group. I think we all want a new stream cipher in TLS to replace RC4. But that's going to take years, and won't help the millions of people who don't replace their software that often. Really? If anything, Firefox and Chromium have shown that new changes can be deployed on the order of weeks-to-months, and with server opt-in (such as NPN/ALPN), the majority of *users* traffic can be protected or enhanced within a few weeks-to-months after. Google already has deployed experimental support, for example. Likewise, the adoption of SPDY - within Firefox and within a number of significant web properties - show that it's significantly quicker than it used to be to protect users. You're correct that there's going to be a long-tail of sites that don't update, sure, but rapid deployment is certainly an increasing possibility for the majority of users. Updates on the client side can be done in a few months, at least for a very large population of the clients. But things tend to break in unexpected ways making and it ussually takes a lot of testing time before it can really be deployed. But I see more problems getting the server side to change. Maybe you can convice some people to disable certain things, but I think it's going to be hard to try to convice them that they should upgrade to a new software version. I've tried and failed. When firefox 27 is released all major browsers will finally support TLS 1.1+ in their latest version. But on the server side we now see about 20% that support it, which is an increase of about 15% over last year. We also still see 25% that still supports SSLv2. At this rate it's still going to take years before you can say that the majority of the sites will support it. I think we should find a way to force them to upgrade, and trying to be as compatible as possible isn't really helping. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 3/01/14 01:06 AM, Julien Vehent wrote: 3DES isn't broken. No, but it is end of life. 112bit security for the 2key variant, and an 8 byte block makes it just old. If you've got AES there, use it. Who hasn't got it? RC4 is broken, but I am yet to see a practical attack that doesn't require gigabits of traffic. What is a real concern is RC4. Anything done to move away from that has to be a good thing. The recent talk by DJB has some real fun descriptions of just how crappy it is becoming. http://financialcryptography.com/mt/archives/001461.html The way I read it, trouble starts at 2^24, that's 16M. By the time you get to 2^30 or 1G it's all over... Caveat -- I'm working from the graphs described from p49 of the talk, I don't pretend to understand them other than what the pictures say. Again, this is the tradeoff between what academia thinks is secure, and the level of security users need. It's more important for us to allow Chinese users to download Firefox, than it is to disable RC4 (that westerners almost never use anyway). Hmmm.. Are the Chinese blocked from stronger crypto? Same goes for the recommendation to use DH parameters 1024 bits. We tried using a 2048 bits parameter a few months back. We first noticed a big spike in CPU usage, caused by the largest exponentiation, but that was still acceptable. What forced the rollback is the long list of java 6 clients that broke, because they don't accept DH keys 1024 bits. Java 6 is covered in mud all over, crypto wise. Maybe time for some nasty words to start circulating. Until all of these clients get fixed, DH params will be limited to 1024 bits. As far as I know stronger DH params are supported by the Java Crypto Extensions package. That said it’s usually not deployed anywhere. We’re aware of the issue but using DH parameters of 1024 bits only can provide security that is slightly less than 1024bit RSA which can certainly be factored by large agencies. - It takes you about 48hours to factor 512bit RSA keys in EC2: http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf - The largest Key factored by public research (in a small university setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006 We hope that Java will adopt a reasonable security policy in the future, although I’m personally not conviced that they will. Problem here is that it isn't so much 'Java' it's more the platforms. Android is stuck on Java 6, and the JCE choices aren't even that modern. http://financialcryptography.com/mt/archives/001450.html Mac OSX has now bailed from Java directly, so one gets it from Oracle/sun directly, which means Java 7. For us, it's a choice between DHE with 1024, or no DHE at all. We will not block a subgroup of users because they don't support larger keys. And I suspect no business ever will. So, on DHE vs !DHE, here's the rationale: RSA key rotations happen very rarely in hosting environments. Except when the CA requires it, it's not uncommon to see private keys that are several years old. Keys also move very easily, end up in people's mailboxes or shared folders, or get stored in cloud providers that don't zero their disks after use. From an operational perspective, the risk of leaking a RSA private key is many times higher than the risk of factoring a DHE key exchange. Even if this key exchange uses half the key size of the RSA key. If an organization wants to spy on Mozilla's DHE traffic, they need to factor *every single key exchange*. On a normal day, that's hundreds of thousands of them. I'm quite certain that the biggest security agencies have clusters than can factor a 1024 DHE key within minutes, but it's still a lot harder and more targeted than factoring one single 2048 RSA key that is used for 5 years. For this reason, we recommend DHE with 1024 bits parameters, and RSA 2048 keys for authentication. I agree with that. I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. AS I've argued before, diversity as an argument seems not to survive in the practical world. But that's something that is contrarian, although it is becoming more mainstream. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
