Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx k...@roeckx.be wrote: On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote: On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote: Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. There must be a misunderstanding. NSS offers Camellia at higher priority than AES in the ClientHello. I think you might be right. I remember testing the new cipher suite order and I was still seeing Camellia being used on https://login.yahoo.com. But, I tried it again now and it is using AES with the new cipher suite order. It is very possible that my original testing of this was off; perhaps due to the HTTP cache or user error. 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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote: On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote: Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. There must be a misunderstanding. NSS offers Camellia at higher priority than AES in the ClientHello. Yes, in the current stable version camellia is often negiotiated if the server supports it because it's almost always above the AES ciphers in the list. The biggest exception to that is ECDHE, because there is no camellia cipher of that. I think that the new order makes more sense, and at least in aurora the order has changed now. Kurt -- 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 Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote: Last week, I also learned that ENISA, a European standards group, recommends Camellia alongside AES as a future-proof symmetric cipher algorithm; see [4]. They recommend: - *_AES_*_GCM_* - *_CAMELLIA_*_GCM_* - *_AES_*_CCM_* Thanks. I filed bug 940119 about adding the TLS_ECDHE_*_CAMELLIA_GCM_* cipher suites. As I already mentioned a few time, I'm still missing some of the *_AES_*_GCM_* ciphers, specially the DHE ones. It should be easy to add TLS_DHE_*_GCM_* cipher suites to NSS. However, I am not sure it is a good idea to add TLS_DHE_*_GCM_* or TLS_RSA_*_GCM_* cipher suites to Firefox (or other browsers, for that matter). Regarding the TLS_DHE_* variants, I think that we should spend some effort on advocating support for the TLS_ECDHE variants first. In particular, you mentioned that Apache 2.2 doesn't support ECDHE. Well, I'd rather work on backporting Apache 2.4's ECDHE support to Apache 2.2 than add the TLS_[DHE_]RSA_*_GCM_* cipher suites to Firefox. Unfortunately, DHE cipher suites don't work well in current Apache 2.2 either, because of the hard-coded 1024-bit parameters. I don't think it would be reasonable to backport the better DHE support from Apache trunk to Apache 2.4 since there are compatibility issues with doing so. Also, ultimately, we'd like to use TLS_ECDHE_* cipher suites for performance reasons. Regarding the TLS_RSA_* variants, like I said before, I think we should avoid adding new cipher suites for RSA key exchange to Firefox, to encourage websites to use the ECDHE variants, which help toward minimizing the fallout of a private key compromise. I am currently expecting that the One-RTT variant of the TLS 1.3 handshake will require ECDHE support anyway. Regardless, I think we can avoid adding those things for now, and revisit this later when we see what happens with TLS 1.3 and when we see how successful (or not) our advocacy attempts are. I think we probably want to still disable Camellia cipher suites by default in the long term anyway, but I did not disable them in Firefox Nightly yet. In order for it to make sense to continue offering Camellia cipher suites long term, we would need to improve NSS's support for Camellia to add the ECDHE variants of the Camellia cipher suites. Currently, I think the best course of action is to let the current configuration ship, then disable Camellia support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so that it is ready in case some problem with AES is found. I don't understand the part where you want to disable it. Originally I was very concerned about the TLS ClientHello message size, because we were under the impression that we had to keep it under 256 bytes. That is the reason I prioritized starting this discussion so highly, in fact. But, at IETF88, we learned that there may be another workaround to the interop problems such that we don't have to keep our ClientHello message size under 256 bytes. Still, we shouldn't be wasteful with our ClientHello message size, since we'll always want to keep it under ~1400 bytes for performance and reliability reasons. 1400 bytes might sound like a lot now, but people have already been talking about TLS extensions that could easily eat up the majority of that space. Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. I am not sure how much the performance or existence of lack of side-channel-free implementations of Camellia matter yet. In Firefox, we've kept Camellia enabled for now, and added some telemetry to measure how often each cipher is used, to inform our future decision making here. 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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 01/11/13 09:41, Dirkjan Ochtman wrote: His Bugzilla status suggests Brian might have left Mozilla: Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you want a response) No, Brian hasn't left Mozilla - he just decided to use a different primary email address. I too would like to see him post a series of next steps for this change. Why can't we just make it (or those bits of it which match the existing implemented ciphers) tomorrow? Gerv -- 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
Mountie Lee moun...@paygate.net wrote: SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. Many people at Mozilla, including us platform engineers, want this too. Our goal is to get rid of plugins on the internet completely. And, also, personally I think it is a great idea for Mozilla to do more to get Firefox working in South Korea. So, I think we all agree on the goals. at last year, adding SEED to WebCrypto API adopted as Action Item. the editor sent question any user agent plan to implement SEED I can not say discussing terminating SEED support in mozilla Whether SEED gets implemented to the WebCrypto API is a separate issue from whether we continue to support SEED in TLS. If we want to add SEED support to WebCrypto then we can do that even if we don't have SEED in TLS. I am not going to promise that we will implement SEED as part of the WebCrypto effort, but I do promise to give it serious consideration. minor algorithm itself has the meaning. it will be helpful for neutralizing or keeping possibilities. I agree that this is a concern. This is one of the reasons we are looking into the Salsa/ChaCha algorithms, as a backup or replacement for AES. Finally, software vendors, including Mozilla, need to work with the Korean government to agree on what to do about the Korean crypto regulations. Mozilla has been supporting SEED for TLS for a long time and it seems to have had no positive impact. If in the future the software industry and the Korean government decide that SEED in TLS is the way forward, then we can add SEED back if we remove it now. However, I am skeptical that the software industry is going to agree that SEED in TLS is the right path forward. Cheers, Brian -- 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 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote: So what needs to happen so that we can move on with this? I still have the same question. Nothing seems to be happening. Kurt -- 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 Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info wrote: It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family. The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any browser If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. This paper: eprint.iacr.org/2007/318.pdf On the complexity of side-channel attacks on AES-256 - methodology and quantitative results on cache attacks - Perhaps my arguments were a little over-stated though. The attack I referenced in the proposal is the related-key attack on reduced-round AES-256. That is something I should have emphasized. Really, I am speculating that this shows that thinking AES-256 is hugely more secure than AES-128 is questionable, but it isn't a slam-dunk case. The side-channel attack paper you cited seems like the more interesting one. It doesn't seem like an argument against AES-256 on its own though, since it still says AES-256 is more difficult to attack through the given side channels than AES-128. So, the main remaining question with AES-256 vs. AES-128 is not whether AES-128 is just as secure as AES-256. Instead, we have to decide whether AES-256 a better security/performance trade-off vs AES-128. I agree with you that the performance numbers for AES-256 vs. AES-128 do not make this a slam-dunk. We should do the measurements on a typical Firefox OS device and see if there is a significant difference there. Until then, unless others suggest otherwise, I think I will just keep the relative ordering of analogous AES-256 and AES-128 cipher suites the same as they are in NSS today. However, it refers to software implementations of AES. Do we know if this result still applies for AESNI? One takeaway from your email is that with AES-NI I don't see a strong case for prefering AES-128 over AES-256. The issue is really what to do about the non-AES-NI case, assuming we all agree that the presence of AES-NI shouldn't affect the order that the client suggests cipher suites in. Thank you very much for taking the time to do these measurements and sharing your insight. 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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Oct 7, 2013 at 4:50 PM, Brian Smith br...@briansmith.org wrote: On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info wrote: It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family. The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any browser If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. This paper: eprint.iacr.org/2007/318.pdf On the complexity of side-channel attacks on AES-256 - methodology and quantitative results on cache attacks - Perhaps my arguments were a little over-stated though. The attack I referenced in the proposal is the related-key attack on reduced-round AES-256. That is something I should have emphasized. Really, I am speculating that this shows that thinking AES-256 is hugely more secure than AES-128 is questionable, but it isn't a slam-dunk case. Hi Brian, all, Related-key attacks are irrelevant to TLS or any standard use of a block cipher. Side-channel attacks against AES just have to recover subkeys from a round or two, so it's not surprising that the difference between 10-round AES128 and 14-round AES256 doesn't make much of a difference. Against non-side-channel cryptanalysis of TLS ciphertext, AES-256 certainly has a higher security margin than AES-128. Trevor -- 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
Hi. thanks for mail. the reason why SEED support give not so much impact is SEED is not used alone but used with other crypto algorithms (hash, asymmetric...) SHA2 hash required in e-commerce transaction by the korean regulation. and which is also used in TLSv1.1+. SEED can be used under TLSv1.1+ environment. as we know, it is just now opened from box. regards mountie. On Tue, Oct 8, 2013 at 3:56 AM, Brian Smith br...@briansmith.org wrote: Mountie Lee moun...@paygate.net wrote: SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. Many people at Mozilla, including us platform engineers, want this too. Our goal is to get rid of plugins on the internet completely. And, also, personally I think it is a great idea for Mozilla to do more to get Firefox working in South Korea. So, I think we all agree on the goals. at last year, adding SEED to WebCrypto API adopted as Action Item. the editor sent question any user agent plan to implement SEED I can not say discussing terminating SEED support in mozilla Whether SEED gets implemented to the WebCrypto API is a separate issue from whether we continue to support SEED in TLS. If we want to add SEED support to WebCrypto then we can do that even if we don't have SEED in TLS. I am not going to promise that we will implement SEED as part of the WebCrypto effort, but I do promise to give it serious consideration. minor algorithm itself has the meaning. it will be helpful for neutralizing or keeping possibilities. I agree that this is a concern. This is one of the reasons we are looking into the Salsa/ChaCha algorithms, as a backup or replacement for AES. Finally, software vendors, including Mozilla, need to work with the Korean government to agree on what to do about the Korean crypto regulations. Mozilla has been supporting SEED for TLS for a long time and it seems to have had no positive impact. If in the future the software industry and the Korean government decide that SEED in TLS is the way forward, then we can add SEED back if we remove it now. However, I am skeptical that the software industry is going to agree that SEED in TLS is the right path forward. Cheers, Brian -- Mountie Lee PayGate CTO, CISSP Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net === PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World -- 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 Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee moun...@paygate.net wrote: SHA2 hash required in e-commerce transaction by the korean regulation. and which is also used in TLSv1.1+. Hi, First, we will be enabling TLS 1.2 in Firefox very soon. But, I think you may be referring to SHA-2-based cipher suites proposed in this internet draft: http://tools.ietf.org/html/draft-bjhan-tls-seed-00 Unfortunately, that internet draft expired and also the draft didn't even specify the cipher suite code points. Where can I find the current version of the Korean regulations on encryption. I have read this article: http://www.koreatimes.co.kr/www/news/biz/2012/04/123_109059.html That article notes that SEED is actually not mandatory in Korea any more. If so, it seems like a good idea to help the Korean community standardize on more common algorithms, right? That article also notes that implementations other than the ActiveX control have to be certified by the Korean government in order to be used. So, it seems like our SEED implementation could not be used legally anyway, since it hasn't been certified. Is that your understanding? My understanding is that the Korean government would also require websites that fall under these regulations to use certificates issued by some Korean certificate authorities. But, Mozilla does include either of the Korean certificate authorities and it seems unlikely to happen soon. See https://bugzilla.mozilla.org/show_bug.cgi?id=335197 Finally, the SEED cipher suite we do currently support does not support ephemeral key exchange. I see that the internet draft I linked to above does attempt to specify SEED cipher suites that support ephemeral key exchange. So, it seems pretty clear to me that it is OK to disable the SEED cipher suite we have currently enabled for now, while we figure out all the things that are necessary to help our Korean users. Cheers, Brian -- 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
Hi. let me add my comment for SEED. SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. the impact of mozilla's effort was not figured out well. but it has meaning and VERY helpful for us to expand web standard environment (plugin free) at last year, adding SEED to WebCrypto API adopted as Action Item. the editor sent question any user agent plan to implement SEED I can not say discussing terminating SEED support in mozilla minor algorithm itself has the meaning. it will be helpful for neutralizing or keeping possibilities. terminating SEED support in mozilla will give very bad impact. it will escalate the impact to other good but minor algorithms or web standard industries. I hope mozilla member understand my comment successfully. regards mountie. On Fri, Aug 9, 2013 at 11:30 AM, 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 -- Mountie Lee PayGate CTO, CISSP Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net === PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World -- 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
let me add one more. SEED is normally used for TLS 1.1+ because the SSL Certificate issued from Korean CA use SHA2 hash algorithm. browser support for TLS 1.1 is limited currently. I expect that is one of the reasons why Korean web servers are not add SEED Cipher suites in SSL configuration. regards mountie. On Wed, Oct 2, 2013 at 6:15 PM, Mountie Lee moun...@paygate.net wrote: Hi. let me add my comment for SEED. SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. the impact of mozilla's effort was not figured out well. but it has meaning and VERY helpful for us to expand web standard environment (plugin free) at last year, adding SEED to WebCrypto API adopted as Action Item. the editor sent question any user agent plan to implement SEED I can not say discussing terminating SEED support in mozilla minor algorithm itself has the meaning. it will be helpful for neutralizing or keeping possibilities. terminating SEED support in mozilla will give very bad impact. it will escalate the impact to other good but minor algorithms or web standard industries. I hope mozilla member understand my comment successfully. regards mountie. On Fri, Aug 9, 2013 at 11:30 AM, 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 -- Mountie Lee PayGate CTO, CISSP Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net -- Mountie Lee PayGate CTO, CISSP Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net === PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World -- 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
-- 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 13/09/13 04:52, Julien Pierre wrote: snip Some servers also ignore the order of cipher suites in the Clienthelo anyway in some cases, and choose whatever they prefer among the client cipher suite list regardless of order, even though this doesn't follow the TLS specs. Julien, I disagree that this doesn't follow the TLS specs. RFC5246 (Section 7.4.1.2) says (emphasis mine): The cipher suite list, passed from the client to the server in the ClientHello... If the list contains cipher suites the server does not recognize, support, *or wish to use*, the server MUST ignore those cipher suites, and process the remaining ones as usual. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- 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 2013-09-12 23:11, Stefan Arentz wrote:
How about mobile?
Mobile is not an issue.
Updated table that contains speed test on Android with an ARMv7 (Galaxy S3):
http://jve.linuxwall.info/ressources/taf/aesmeasurements.txt
You can see that the ARM7 does AES-{128,256} in the 50 to 70MB/s range. I
was actually surprised by the results, I had no idea ARMs cpus could compute
AES that fast, and all in software since there's no AES-NI in ARM (yet...).
What about the initial key exchange that SSL/TLS does? I thought that was
the
biggest CPU killer?
Absolutely. And that's still true. I'm only discussing AES-128 vs AES-256
here.
- Julien
--
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 2013-08-26 17:24, Brian Smith wrote: Conversely, it isn't clear that AES-256 offers any significant security advantage over AES-128, though it is clearly slower, even on my AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well so that it might just be good enough in general. I ran some measurements on various CPUs, including slow ones, both with and without AES-NI. The full table is at the end of this email. It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family. With one exception: AESNI on Intel i7. On this CPU, and for block sizes of 16 64, 256 and 1024 bytes, AES-256 is ~80% slower than AES-128. For a block size of 8192 bytes, AES-256 is 28.7% slower. The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any browser If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. Secondly, as I already pointed out in my proposal, some research has shown that AES-256 doesn't seem to offer much more security than what we understand AES-128 to offer. See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time implementations are used, AES-256 seems to offer more opportunity for timing attacks than AES-128 does, due to more rounds and larger inputs. This paper: eprint.iacr.org/2007/318.pdf On the complexity of side-channel attacks on AES-256 - methodology and quantitative results on cache attacks - Seems to suggest something similar: In this paper, we addressed side-channel attacks on AES-256: we demonstrated with practical results that the complexity (i.e. resistance) increase with the number of key bits is virtually non-existent. In particular, for the cache based attacks, an attack on AES-256 is only 6 to 7 times as hard as an attack on AES-128 both in the required computing power as in the required number of observations. We used the cache side- channel as an example side-channel, but the methodology presented in this work can be applied to leverage any other channel and attack AES-256. However, it refers to software implementations of AES. Do we know if this result still applies for AESNI? --- Julien Vehent http://jve.linuxwall.info --- Speed measurements of AES on several families of CPUs --- | type| 16_bytes | 64_bytes | 256_bytes | 1024_bytes | 8192_bytes | CPU ---+-++++++-- AESNI | aes-128-cbc | 669744.67k | 720971.18k | 754488.83k | 758975.49k | 754668.89k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz AESNI | aes-192-cbc | 580606.16k | 618596.46k | 630121.39k | 630994.60k | 633320.79k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz AESNI | aes-256-cbc | 507602.55k | 534540.84k | 544787.63k | 540530.35k | 543763.11k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz regular| aes-128-cbc | 138017.61k | 150701.59k | 154806.19k | 153791.49k | 156374.36k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz regular| aes-192-cbc | 117436.95k | 126625.64k | 128216.15k | 129753.77k | 130247.34k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz regular| aes-256-cbc | 102283.73k | 109657.30k | 111773.61k | 112319.15k | 112596.31k | Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz ---+-++++++-- AESNI | aes-128-cbc | 574168.83k | 612081.11k | 620871.25k | 626095.10k | 623520.43k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz AESNI | aes-192-cbc | 122382.52k | 130687.70k | 136055.47k | 151552.68k | 395365.03k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz AESNI | aes-256-cbc | 111402.54k | 114350.49k | 125160.36k | 174099.46k | 443987.29k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz regular| aes-128-cbc | 2.35k | 33039.47k | 86861.99k | 127958.36k | 128316.76k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz regular| aes-192-cbc | 24563.96k | 26540.95k | 32132.95k | 36337.66k | 71385.09k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz regular| aes-256-cbc | 21766.37k | 29087.62k | 26345.47k | 25728.00k | 27989.33k | Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz ---+-++++++-- AESNI | aes-128-cbc | 27391.57k | 42004.99k | 49039.45k | 51120.81k | 51716.10k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT) AESNI | aes-192-cbc | 24954.17k | 36496.21k | 41651.46k | 43204.27k | 43677.01k | Intel(R) Atom(TM) CPU D510 @ 1.66GHz (NO AESNI SUPPORT) AESNI | aes-256-cbc | 22912.58k | 31863.87k | 35590.14k | 36657.49k | 36975.96k | Intel(R)
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Julien, On 9/12/2013 07:06, Julien Vehent wrote: If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. The performance is still an issue for servers. More servers are needed if more CPU-intensive crypto algorithms are used. Julien -- 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 2013-09-12 22:01, Julien Pierre wrote: Julien, On 9/12/2013 07:06, Julien Vehent wrote: If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. The performance is still an issue for servers. More servers are needed if more CPU-intensive crypto algorithms are used. aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES bandwidth on a single core. On a decent 8 core load balancer, dedicate 4 to TLS, and you get 17.40Gbps of AES bandwidth. I don't this AES is close to being the limiting factor here. Processing HTTP is probably 20 times more expensive than that. Just reinforcing the point that performance is not, in my opinion, an issue. The quality of AES-256 is much more relevant here. --- Julien Vehent http://jve.linuxwall.info -- 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
How about mobile? What about the initial key exchange that SSL/TLS does? I thought that was the biggest CPU killer? S. - Original Message - From: Julien Vehent jul...@linuxwall.info To: Julien Pierre julien.pie...@oracle.com Cc: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Thursday, September 12, 2013 10:35:06 PM Subject: Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers On 2013-09-12 22:01, Julien Pierre wrote: Julien, On 9/12/2013 07:06, Julien Vehent wrote: If performance was the only reason to prefer AES-128, I would disagree with the proposal. But your other arguments regarding AES-256 not provided additional security, are convincing. The performance is still an issue for servers. More servers are needed if more CPU-intensive crypto algorithms are used. aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES bandwidth on a single core. On a decent 8 core load balancer, dedicate 4 to TLS, and you get 17.40Gbps of AES bandwidth. I don't this AES is close to being the limiting factor here. Processing HTTP is probably 20 times more expensive than that. Just reinforcing the point that performance is not, in my opinion, an issue. The quality of AES-256 is much more relevant here. --- Julien Vehent http://jve.linuxwall.info -- 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
Julien, On 9/12/2013 19:35, Julien Vehent wrote: aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES bandwidth on a single core. On a decent 8 core load balancer, dedicate 4 to TLS, and you get 17.40Gbps of AES bandwidth. I don't this AES is close to being the limiting factor here. Processing HTTP is probably 20 times more expensive than that. That's not correct. Basic HTTP processing is much less CPU intensive than the overhead of SSL/TLS, regardless of which cipher suite used, usually by at least an order of magnitude. The crypto is very much the limiting factor. Choosing a more CPU intensive algorithm will result in more server hardware being required in general in data centers. Of course, the server can always disable AES-256 cipher suites altogether if it doesn't want to spend cycles on it. It would then choose the AES-128 cipher suites if the client also had them enabled, which I believe is the case in this proposal. Only an ordering change is proposed. Some servers also ignore the order of cipher suites in the Clienthelo anyway in some cases, and choose whatever they prefer among the client cipher suite list regardless of order, even though this doesn't follow the TLS specs. Julien -- 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 Mon, Sep 09, 2013 at 07:20:57PM +0100, Rob Stradling wrote: Probably worth keeping an eye on this new draft and the related discussion on the TLS list... http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 Note that the recommended cipher there isn't in Brian's proposal, and I've already pointed that out. Kurt -- 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 Friday, August 9, 2013 5:30:26 AM UTC+3, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html Thank you for this. I'm a bit skeptical about whether eliminating handshake fingerprinting is worth the disincentive to improve the set of ciphersuites. And I'm skeptical about actually getting to a state where all browsers have the same handshake in the first place. If there was a single ciphersuite that was known to be the one everyone should use for all future and the other ciphersuites were around just for compatibility with legacy servers (analogous to UTF-8 and other character encodings), I think it would make sense to freeze the handshake. However, since encryption is supposed to get stronger over time, having a frozen handshake would block improvements. Is it really realistic that other browsers would agree not to offer better ciphersuites as soon as they can get them implemented until all browsers agree that new ciphersuites should be included? On the other hand, if other browsers adopted the same handshake as Firefox, would it be better for Firefox to keep the common handshake than to introduce better ciphersuites as they become available? If the common handshake isn't achievable or desirable, I wonder if it's a good idea to drop Camellia altogether. I know nothing about the merits of Camellia relative to AES (maybe they are even similar enough for attacks to be transferable; dunno), but a reduction in algorithm agility seems scary on an uninformed gut level. If one assumes that handshakes won't be unified across browsers, wouldn't it then make sense, space permitting, to keep around at least one forward-secret RSA+Camellia ciphersuite in case a disaster strikes AES? What the threat being defended against in the handshake fingerprinting case? At least network eavesdroppers near the browser will have plenty of adjacent plain HTTP traffic with UA strings to capture for the foreseeable future and the site being connected to gets the UA string anyway. -- 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 22/08/13 11:50, Alan Braggins wrote: On 21/08/13 18:23, Zack Weinberg wrote: I share concern about new side channel attacks due to GMAC, though. You aren't alone. https://bugzilla.mozilla.org/show_bug.cgi?id=868948 I asked a friend who works for ARM about the chances of constant time AES-GCM instruction set support. SecurCore; sure. A-series; no chance. I'm not convinced that the advantages of eliminating handshake fingerprinting outweigh the benefits of allowing endpoints with different capabilities to negotiate different ciphers (e.g. preferring AES more strongly if AES-NI instructions are available at both ends). Possibly you should be aiming for a shared set of principles to be used by browsers when choosing a suite, not a shared ordering. -- 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 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Gerv -- 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 Mon, Sep 9, 2013 at 5:16 PM, Gervase Markham g...@mozilla.org wrote: This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? I don't think other prominent cryptographers necessarily agree: http://www.slideshare.net/astamos/bh-slides https://twitter.com/tqbf/status/376710977669984256 Cheers, Dirkjan -- 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 Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn’t he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? S. -- 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 Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote: On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- 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
The NSA recommends ECC for encrypting secret and top secret information. So if the NSA have backdoored the NIST curves somehow, presumably they're 100% confident that the details of the backdoor won't get leaked or discovered by external researchers! On 09/09/13 17:15, Kurt Roeckx wrote: On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote: On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- 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
Probably worth keeping an eye on this new draft and the related discussion on the TLS list... http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 On 09/09/13 17:15, Kurt Roeckx wrote: On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote: On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- 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
So what needs to happen so that we can move on with this? Kurt -- 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 Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@redhat.com wrote: So looking at this list, I think we have a major inconsistency. We put Ephemeral over non-ephemeral, but we put 128 over 256. While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think in doing so we are taking a much more significant performance hit we get back by putting 128 over 256. It is not exactly true that PFS always has more of a negative performance impact than AES-128 vs AES-256. In Chromium, PFS ciphersuites will be faster than non-PFS cipher suites because Chromium requires PFS ciphersuites to be used for False Start. Also, I have an idea for how we can make PFS cipher suites + False Start work much more commonly on the web, that won't work for RSA key exchange. So, ultimately, I expect PFS cipher suites to be a performance win over non-PFS cipher suites. But, raw performance isn't the only issue. We expect that PFS cipher suites *can* have significantly better security properties (see below) if the server puts in the effort to make the encryption keys actually ephemeral, and we expect that they are generally no worse they are no worse regarding security (barring disastrous implementation errors). Conversely, it isn't clear that AES-256 offers any significant security advantage over AES-128, though it is clearly slower, even on my AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well so that it might just be good enough in general. Secondly, as I already pointed out in my proposal, some research has shown that AES-256 doesn't seem to offer much more security than what we understand AES-128 to offer. See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time implementations are used, AES-256 seems to offer more opportunity for timing attacks than AES-128 does, due to more rounds and larger inputs. The attack profile protection of PFS versus non-PFS is basically two points: 1) some government agency could force a server to give up it's private keys and decrypt all the traffic sent to that server. But we already know that government agencies with such power simply ask for the the data on the server. This argument seems to assume that all the data that was transferred over the network is stored on the server. But, this is not necessarily the case. I don't think that is a reasonable assumption. The site may have already deleted the data (perhaps at the request of the user) from the server. Also, there is a lot of transient data that is never stored anywhere. Finally, sometimes it is more interesting for the attacker to know what data was transmitted than to know what data is on the server. For example, if somebody is trying to prosecute me for posting my album collection to MegaUpload, the existence of the album data on the MegaUpload server may not be too useful, whereas a record of me doing the upload of that data with my actual credentials may be. I still think PFS algorithms are useful and agree with preferring them, but compared to 128 versus 256 it seems like the cost/security tradeoffs are actually less for the PFS algorithms. First, I agree with the overall idea that the performance cost of AES-256 over AES-128 isn't huge. However, I do think that it is significant, at least for mobile clients where such concerns are most critical--not just speed, but also battery life. We can gather the numbers (perhaps others already have them) if that helps. Something to note is that MSIE has always put AES-128 cipher suites ahead of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS cipher suites, though. Cheers, Brian -- 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 Mon, Aug 26, 2013 at 2:24 PM, Brian Smith br...@briansmith.org wrote: Something to note is that MSIE has always put AES-128 cipher suites ahead of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS cipher suites, though. I meant: MSIE has always put AES-128 cipher suites ahead of **AES-256** cipher suites. 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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 08/26/2013 02:24 PM, Brian Smith wrote: On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@redhat.com wrote: So looking at this list, I think we have a major inconsistency. We put Ephemeral over non-ephemeral, but we put 128 over 256. While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think in doing so we are taking a much more significant performance hit we get back by putting 128 over 256. It is not exactly true that PFS always has more of a negative performance impact than AES-128 vs AES-256. In Chromium, PFS ciphersuites will be faster than non-PFS cipher suites because Chromium requires PFS ciphersuites to be used for False Start. Also, I have an idea for how we can make PFS cipher suites + False Start work much more commonly on the web, that won't work for RSA key exchange. So, ultimately, I expect PFS cipher suites to be a performance win over non-PFS cipher suites. So at this point I want to point out that: 1) I don't disagree with PFS before the other ciphers, I just wanted to point out that they are not clearly as big a win for security as is normally touted. 2) It does have a significant downside speed wise. I was responsible for measuring this once from the server perspective (we were trying to convince people to use ECC. I could only get wins over RSA at the 2048 bit range with ECDH (224bit) not ECDHE... and that was ECDHE where we used a single private key generated at server startup). Note that we are using 256 bit ECC at the low end. Those figures are old, so it would be good to try to get new ones from the client perspective (not how many connections a server can use). I'm not as worried about the order for servers as servers can manage their performance by only supporting the fast algorithms. But, raw performance isn't the only issue. We expect that PFS cipher suites *can* have significantly better security properties (see below) if the server puts in the effort to make the encryption keys actually ephemeral, and we expect that they are generally no worse they are no worse regarding security (barring disastrous implementation errors). Conversely, it isn't clear that AES-256 offers any significant security advantage over AES-128, though it is clearly slower, even on my AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well so that it might just be good enough in general. So as I pointed out, we should list performance measurements as to the difference in cost. If you can see the difference, simply include those numbers. Secondly, as I already pointed out in my proposal, some research has shown that AES-256 doesn't seem to offer much more security than what we understand AES-128 to offer. My bad, I missed that point. Sorry. See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time implementations are used, AES-256 seems to offer more opportunity for timing attacks than AES-128 does, due to more rounds and larger inputs. This is argument does have teeth, probably more than the performance (depending on the actual performance). When using performance as a criteria at all, it should be quantified. For clients 3x slower doesn't mean anything if it's 3x 100 microseconds, but if its 3x 1s it makes a big difference. We should measure both on big platforms and small ones. So in summary. 128 is actually considered as secure as 256 (based on recent attacks) or better (based on timing attacks), so performance isn't the primary criteria. If we were to shop this list around to other browsers, it would probably be good to get the performance numbers. Particularly ECDHE 256 versus RSA 2048 on an arm (If that doesn't show a significant cost, we can safely say performance of the key exchange is negligible). bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Aug 26, 2013 at 05:16:43PM -0700, Robert Relyea wrote: 2) It does have a significant downside speed wise. I was responsible for measuring this once from the server perspective (we were trying to convince people to use ECC. I could only get wins over RSA at the 2048 bit range with ECDH (224bit) not ECDHE... and that was ECDHE where we used a single private key generated at server startup). Note that we are using 256 bit ECC at the low end. Those figures are old, so it would be good to try to get new ones from the client perspective (not how many connections a server can use). I'm not as worried about the order for servers as servers can manage their performance by only supporting the fast algorithms. See http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html I think this is the most relevant one. Most of the others compare it to 1024 RSA keys. Only about 4% is still using 1024 keys now, while the rest is using 2048 or more. Kurt -- 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 22/08/13 19:21, Robert Relyea wrote: The attack profile protection of PFS versus non-PFS is basically two points: 1) some government agency could force a server to give up it's private keys and decrypt all the traffic sent to that server. But we already know that government agencies with such power simply ask for the the data on the server. 2) some well funded attacker could spend the resources to attack the server's private key and get all the traffic sent to it. However, we don't actually check to see that the server is giving us a unique key in the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is to generate a single them key as use it for all connections. We have know way of knowing the server is doing this, which brings back this particular attack. 3) Someone who has captured some or all of the traffic could use a 0-day to get into the server and pinch the private key. This sort of thing is much more likely if the victim is a person of noteworthiness and the attacker is a government (perhaps that person's government), but is not the government of the jurisdiction where the server is based. As for 2), there are lots of ways a server can sabotage a seemingly-encrypted connection if it chooses. Why is this one special? Gerv -- 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 08/23/2013 02:03 AM, Gervase Markham wrote: On 22/08/13 19:21, Robert Relyea wrote: The attack profile protection of PFS versus non-PFS is basically two points: 1) some government agency could force a server to give up it's private keys and decrypt all the traffic sent to that server. But we already know that government agencies with such power simply ask for the the data on the server. 2) some well funded attacker could spend the resources to attack the server's private key and get all the traffic sent to it. However, we don't actually check to see that the server is giving us a unique key in the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is to generate a single them key as use it for all connections. We have know way of knowing the server is doing this, which brings back this particular attack. 3) Someone who has captured some or all of the traffic could use a 0-day to get into the server and pinch the private key. This sort of thing is much more likely if the victim is a person of noteworthiness and the attacker is a government (perhaps that person's government), but is not the government of the jurisdiction where the server is based. This has the same characteristics as 1. Once in the server, it's more likely the attacker will fetch the data at rest than try to decrypt recorded SSL connection. Once the private key is pinched, future connections are vulnerable even if they are PFS. As for 2), there are lots of ways a server can sabotage a seemingly-encrypted connection if it chooses. Why is this one special? Most ways the server could sabotage the connection are detectable to the client. I'm also pointing out that PFS is not a panacea. It's often touted as such, but it's relatively easy to defeat. To be clear, I'm not against PFS, and I don't disagree that it should be placed forward, what I am pointing out is that any argument based on performance to put 128 over 256 is completely ignoring the fact that PFS is at least 3 times as expensive as the equivalent non-PFS algorithms for only marginal theoretic security enhancement. I think we need to be consistent in our choices here (of course as a security guy, I'm quite happy with security over performance as the default). bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 21/08/13 18:23, Zack Weinberg wrote: On 2013-08-19 2:06 PM, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM is (AIUI) preferred because it's immune to BEAST. The TLS1.1 explicit IV is sufficient for immunity to that specific attack even when using CBC mode. http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack I share concern about new side channel attacks due to GMAC, though. You aren't alone. https://bugzilla.mozilla.org/show_bug.cgi?id=868948 salsa20 + poly1305 anyone? -- 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 08/19/2013 11:06 AM, Kurt Roeckx wrote: On 08/09/2013 04:30 AM, Brian Smith 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. So I think there are a whole bunch of things where we have 2 options, and it's not always clear which is more important. We have: - PFS or not - ECC or not - RSA or DSA - GCM or CBC - keysize (128 vs 256) - cipher itself - The used MAC As far as I understand things, most of those don't have a big impact on security, but do on the speed. It's not that simple. Which individual algorithm is faster is often platform and key size dependent. The traditional ordering has been security first, then performance among equivalent. Things like Camellia and SEED were placed high assuming that server support for them would be rare, so the would be negotiated on those servers that needed them. I think it makes sense to have PFS when the other side supports it, so that part of the order looks good to me. We clearly want (EC)DHE when possible. DH should probably be avoided. So, to be clear about ECDHE and DHE, the server *CAN* provide perfect forward secrecy, but it doesn't have to. The ephemeral key could simple be another permanent key (or one of several thousands). It's important to note that a properly implemented DHE/ECDHE is 3 times slower than DH or ECDH (The latter does a signature, key gen, and key derive (each doing one group operation), the former simply does a derive). This cost is born by the server. I understand that ECC might be more secure and is faster, so you want to prefer ECC. But currently there aren't many servers that have ECDHE yet, so we should be careful what the order is in case it's not available and try to use DHE in that case. The current list didn't do that but this one does. This is ECC marketing. When we did the measurements (10 years ago), RSA was significantly faster on modern 64-bit machines than ECC at the 1024 bit level, and a push at the 2048 bit level (this is measuring SSL connection performance). That is assuming ECDH. ECDHE is 3 times slower than ECDHE. RSA gets a one for one performance boost every time you increase the speed of the modular multiply. where as ECC only gets 20% or so of that. The ECC win is that ECC is more secure at lower key sizes, and it's security profile is linear. RSA's security profile is exponential: Example of typical equivalences: Symmetric 80 ECC 160 RSA 1024 Symmetric 128ECC 256 RSA 2048 Symmetric 192ECC 384 RSA 4096 Symmetric 256ECC 512* RSA 8K (The actual prime ECC curve is 521 simply because 2^521-1 is prime) ECC is faster than RSA at low key sizes on restricted hardware (once ECC is optimized, that is). On faster hardware RSA holds it's own into the 2K range. to double your security, RSA needs to go up about 4x. Also doubling your key size increase the cost to do the RSA operation by 4x. ECC is linear in both cases. So if RSA is 16x faster than RSA at one strength level, doubling it would make them equivalent. The upshot is that ECC will always eventually win the performance race at the top end, but for any given hardware and key strength, RSA may actually be faster. I'm not sure which of RSA and DSA is better, but clearly people use RSA more. DSA is signature only, so it's DHE/DSA versus DHE/RSA versus RSA. Both algorithms are have different speed characteristics. In RSA signing is more expensive verification, but still cheaper than DSA signing (unless you precalculate several k/r/k^-1 values, which hardware may do, but most software does not bother with). For verification RSA is significantly faster (why, you may ask, since the math for both is exactly the same: S =H^priv mod N, H = S^pub mod N? It's because we can choose the value of the public key and greatly reduce our work to calculate X^pub mod N). DSA verification is actually slower than DSA signing, involving 2 group operations (modular exp in the case of DSA), and invert and 3 multiplies. Of core RSA is much faster than any of the DHE/DSA, DHE/RSA for both the client and the server. It's also faster than DH_ for the same key sizes (RSA private key ops can use the Chinese remainder theorem to reduce it's work by 4x, verses DH of the same key size). I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. Again, GCM is not necessarily faster than CBC, though GCM doesn't have to do the hash. Certainly on a 64 bit intel machines with hardware assist, it's likely to be. GCM isn't vunerable to BEAST attacks. I understand that for a 2048 bit public key a 128 bit symmetric key should be good enough, but for a 4096 you should have a larger key. I see that about 2% is using keys of 4096 bit. It's a question of where your weakest link is. 2048
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 08/16/2013 03:05 PM, Wan-Teh Chang wrote: 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. So looking at this list, I think we have a major inconsistency. We put Ephemeral over non-ephemeral, but we put 128 over 256. While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think in doing so we are taking a much more significant performance hit we get back by putting 128 over 256. The attack profile protection of PFS versus non-PFS is basically two points: 1) some government agency could force a server to give up it's private keys and decrypt all the traffic sent to that server. But we already know that government agencies with such power simply ask for the the data on the server. 2) some well funded attacker could spend the resources to attack the server's private key and get all the traffic sent to it. However, we don't actually check to see that the server is giving us a unique key in the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is to generate a single them key as use it for all connections. We have know way of knowing the server is doing this, which brings back this particular attack. I still think PFS algorithms are useful and agree with preferring them, but compared to 128 versus 256 it seems like the cost/security tradeoffs are actually less for the PFS algorithms. If we are making performance tradeoffs, we really should measure the real cost rather than just randomly say one is too expensive. 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. Agreed SHA256 HMAC, like PFS, is really marketing. SHA1 is weak right now for signatures because of collision, but HMAC depends on pre-image resistance, which even MD-5 is still strong against. At some point marketing wins, as well as the security principle attacks only get better. As Brian points out, however, AEAD cipher suites solve both problems. bob Wan-Teh smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 19/08/13 19:06, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM (while recognizing that it isn't widely supported yet). (At least unless http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-00 gets anywhere - the current choice isn't so much GCM or CBC as GCM or MAC-then-encrypt-CBC. Personally I don't see very much point in Peter's proposal - supporting the new extension won't be that much less work than GCM, and GCM suites are already standardized.) -- 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 2013-08-19 2:06 PM, Kurt Roeckx wrote: I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. GCM is (AIUI) preferred because it's immune to BEAST. I share concern about new side channel attacks due to GMAC, though. As far as I understand it, there is nothing wrong with 3DES other than that it's slower. I am under the impression that the 64-bit block size is also considered a serious flaw nowadays. zw -- 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 2013-08-20 2:33 PM, Tom Ritter wrote: On 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote: On 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. But if Tor Browser is based on Firefox, then it'll have the same TLS signature as Firefox anyway? Not Tor Browser, but the Tor protocol itself. For more information, the spec document that deals with this is: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt I expect if all the browsers change their ciphersuite selection, Tor will follow suit. Looking like an *old* browser would eventually become suspicious. zw -- 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 08/09/2013 04:30 AM, Brian Smith 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. So I think there are a whole bunch of things where we have 2 options, and it's not always clear which is more important. We have: - PFS or not - ECC or not - RSA or DSA - GCM or CBC - keysize (128 vs 256) - cipher itself - The used MAC As far as I understand things, most of those don't have a big impact on security, but do on the speed. I think it makes sense to have PFS when the other side supports it, so that part of the order looks good to me. We clearly want (EC)DHE when possible. DH should probably be avoided. I understand that ECC might be more secure and is faster, so you want to prefer ECC. But currently there aren't many servers that have ECDHE yet, so we should be careful what the order is in case it's not available and try to use DHE in that case. The current list didn't do that but this one does. I'm not sure which of RSA and DSA is better, but clearly people use RSA more. I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. I understand that for a 2048 bit public key a 128 bit symmetric key should be good enough, but for a 4096 you should have a larger key. I see that about 2% is using keys of 4096 bit. As far as I understand it, there is nothing wrong with 3DES other than that it's slower. RC4 should clearly be deprecated, but is currently popular because BEAST and that it's the only stream cipher we have. Since we know we're not vulnerable to that, it make sense to order this as late as possible. It might not be obvious, but camellia is currently used a lot when connecting to sites because it's the first non-ECDHE in the current list. And the RSA key-exchange was even before the DHE version. I understand that the MAC itself doesn't make much difference, but we should probably avoid MD5. I see no SHA256 MACs except for GCM which probably isn't a problem. So I can mostly follow the reasoning behind the proposed order, but I'm a little bit surprised that we used to have all the 256 bit before the 128 bit, and it's now the other way around. I don't really see this as a problem except for people that want to use 4096 bit public keys. They should probably disable 128 bit keys on their server. I'm not sure why you keep TLS_DHE_DSS_WITH_AES_128_CBC_SHA and drop TLS_DHE_DSS_WITH_AES_256_CBC_SHA I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's the only one with PFS that some sites support. Can I suggest you add that before the ECDHE_*_RC4 ciphers? Kurt -- 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 Mon, Aug 19, 2013 at 08:06:49PM +0200, Kurt Roeckx wrote: I understand that the MAC itself doesn't make much difference, but we should probably avoid MD5. I see no SHA256 MACs except for GCM which probably isn't a problem. I'm having mixed feelings about SHA1 / SHA256. I think it makes sense to move to SHA256 even when SHA1 isn't broken as used here. But since we do this already use it for GCM, and that's on top of the list, I think it's fine. I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's the only one with PFS that some sites support. Can I suggest you add that before the ECDHE_*_RC4 ciphers? I also just noticed that all GCM suites we have are ECDHE versions. I would like to have a DHE version too since apache 2.2 doesn't support ECDHE but does have support for the DHE GCM ciphers. I would like to see that as first non-ECDHE cipher in the list. Kurt -- 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 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. But if Tor Browser is based on Firefox, then it'll have the same TLS signature as Firefox anyway? Gerv -- 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 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote: On 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. But if Tor Browser is based on Firefox, then it'll have the same TLS signature as Firefox anyway? Not Tor Browser, but the Tor protocol itself. For more information, the spec document that deals with this is: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt -tom -- 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 Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson ch...@randomnonce.orgwrote: 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. I think your argument is more about the Future work: A comprehensive profile for browsers' use of TLS part of the document, since the fingerprinting that OpenSSL is now using to detect Safari 10.8 uses the presence and ordering of TLS extensions like SNI that are not in the scope of the current proposal. Although I think browsers could now realistically all agree on the sequence of ciphersuites to offer by default in their client hello, we're far from standardizing on the contents of the entire client hello. Let's defer the debate the pros/cons of completely eliminating fingerprinting in TLS until it is more realistic to do so (if ever). Cheers, Brian -- 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 2: The proposal is not clear. I want an algorithmic definition. snip 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). That sounds reasonable to me. I did not invest too much effort on making the results computable from the rationale section because I think it is likely that a lot (or all) of the rationale section would be reduced or removed from any IETF internet draft that proposed a web browser profile of TLS. On 3: 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. Now that NSS has AES-GCM, we have an alternative to HMAC-SHA1. Also, if we are a little presumptuous, we can expect to have a third alternative in Salsa20/12+(UMAC|VMAC|Poly1305) sometime in the near future. If we find it is important to offer HMAC-SHA256/384 later, we can do so then. But, if we add them now, we will have difficulty removing them later. If we have enough space in the handshake I see no problem in including them. We will have to determine whether the 256-byte client hello limitation is really something that we have to deal with in the long term. But, even if that turns out now to be something we need to ever worry about, I would still be against adding HMAC-SHA256/384 when there seem to be better alternatives that do not regress performance from what we're offering now. Cheers, Brian -- 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 5:58 PM, Wan-Teh Chang w...@google.com wrote: 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. I agree that the ordering of ECDSA vs. RSA is mostly a symbolic gesture at this point in time due to the small number of websites that have both types of certificates, and the motivations for those sites to have both types. But, I don't think we should base the order that browsers choose based on this symbolic meaning; instead, we should base the ordering on what gives the client the best security/performance/compatibility tradeoff. I am not sure that we can say that ECDSA is more secure than RSA in a meaningful way. The old Debian OpenSSL bug and the new Android OpenSSL bug both offer some empirical evidence that implementation errors in PRNGS are more likely to reduce security than the theoretical concerns that would indicate that ECDSA is generally more secure than RSA. Also, the minimum RSA key size that is acceptable according to the baseline requirements is 2048 bits. For digital signatures, there seems to be quite a significant margin between what seems to be needed to authenticate a single TLS handshake and the security level that RSA 2048 offers. If we assume that websites will generally choose the smallest/fastest key that is considered acceptable according to the CABForum baseline requirements (RSA 2048 and ECDSA P-256) then especially on ARM there is quite a performance advantage for the client to get an RSA signature instead of an ECDSA signature. If the server is choosing which certificate to use based on the client's preferences instead of its own performance needs, then the client should be suggesting what is best for the client, on the assumption that the server is making a rational decision. More generally, the ordering I suggested isn't intended to be the ordering that servers should use if they are configured to disregard the client's preferences. For example, many servers wouldn't want to choose CBC-based ciphersuites over RC4 yet if they are concerned about BEAST or Lucky 13. But, for NSS-based clients, it does make sense to choose the CBC-based ciphersuites in the proposal over RC4 because the NSS-based clients have implemented fixes for BEAST and Lucky 13, but not for the RC4 issue. I will update the proposal to mention these things. 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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 18:12, Brian Smith wrote: No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 . This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules. OK. So you are choosing from a fixed palette, and changing that palette is outside the scope of this proposal? It is possible to add new cipher suites, but new cipher suites should have substantial value and a realistic shot at becoming widely-deployed. I agree this is theoretically possible but, as Tom points out, if we posit an attacker who can see your traffic, the chances of you concealing the identity of your user agent from him are pretty small. When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) Do you have suggestions for who to contact? The first person I would talk to would be Gen Kanai g...@mozilla.com, although he may put you in touch with others. Thanks. I will send ask him to forward a link to these threads to the people he thinks may be interested in it. Cheers, Brian -- 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 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
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
I believe this plan would have poor side effects. For example, if Apple ships clients with a broken ECDSA implementation [0], a server cannot detect detect if a connecting client is an Apple product and avoid the use of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes unsafe for anyone to use anywhere. [0]: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith br...@briansmith.org wrote: Please see https://briansmith.org/browser-ciphersuites-01.html First, this is a proposal to change the set of sequence of ciphersuites that Firefox offers. Secondly, this is an invitation for other browser makers to adopt the same sequence of ciphersuites to maximize interoperability, to minimize fingerprinting, and ultimately to make server-side software developers and system administrators' jobs easier. Suggestions for improvements are encouraged. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 08/09/2013 10:12 AM, Brian Smith wrote: On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote: * Can you provide some background or references on exactly how ciphersuite construction and choice works? Can I invent e.g. TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of elements? Can any combination be encoded in the ClientHello? Does the server support specific sets, or will it support my combination if it supports all the component pieces? No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules. Minor tweak. The design point has nothing to do with crypto modules. It had to do with analyzing combinations of algorithms. In 1994/5 when SSL-3 was being designed there were 2 camps: 1) select Asymmetric/Symmetric/Macing algorithms separately and 2) cipher suites. The security argument fell to cipher suites under the theory that it simplified your analysis of whether the algorithm is secure or not. At the time no one was thinking of doing operations in tokens, even at this point in time, I know of no crypto modules that actually implement cipher suites as a suite. That info is really only of historical interest and doesn't affect the rest of Brian's argument (particularly since he's correct in the only part of the paragraph Gerv cares about --- that SSL uses suites, not arbitrarily mixed combinations of algorithms). smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 09/08/13 18:12, Brian Smith wrote: No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules. OK. So you are choosing from a fixed palette, and changing that palette is outside the scope of this proposal? There is a difference between leaking to somebody on the network and leaking to the server you are connecting to. Remember that TLS hides the User-Agent string and other HTTP-level information is hidden from others on the network. So, if Firefox for Android and Firefox for Desktop use the exact same TLS handshaking logic/parameters, then it should be possible to make them indistinguishable from each other. I agree this is theoretically possible but, as Tom points out, if we posit an attacker who can see your traffic, the chances of you concealing the identity of your user agent from him are pretty small. When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) Do you have suggestions for who to contact? The first person I would talk to would be Gen Kanai g...@mozilla.com, although he may put you in touch with others. Gerv -- 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
Hi Brian, On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html Suggestions for improvements are encouraged. Thanks for this. Here are my questions: * Can you provide some background or references on exactly how ciphersuite construction and choice works? Can I invent e.g. TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of elements? Can any combination be encoded in the ClientHello? Does the server support specific sets, or will it support my combination if it supports all the component pieces? * We should avoid leaking the distinction between mobile and desktop products in the TLS handshake, which means that the handshake should look the same on mobile and desktop. Why is this a goal? There are many, many other ways of determining this distinction, some supported by Mozilla (e.g. the UserAgent string). This is not to deny that there are other reasons for having a consistent set, but this seems an odd one. The same question applies to your point about avoiding TLS fingerprinting. I think it should be a goal to make it hard to distinguish between specific instances of Firefox, but it seems to be not a goal to avoid people distinguishing between Firefox and IE, or Firefox for desktop and Firefox for Android. * this proposal does not recommend supporting the CBC-HMAC-SHA-2-based ciphersuites that those browsers recently added Can you spell out why? Is it because they don't offer forward secrecy? * In the course of testing TLS 1.2 and the ALPN TLS extension, the Chromium team recently found that some servers choke when the ClientHello message in the TLS handshake is larger than 256 bytes. How many bytes are taken up per ciphersuite? How many can we probably fit in, if we say we need to include all the other stuff? * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) * Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS. However, if we never use them, then have to switch to them because a problem arises with HMAC-SHA-1, how will they have received any testing? More generally, is there a place for including ciphersuites 'of the future', perhaps at lower priority, to try and make sure there aren't problems or interop issues with them? * Your final section says what cipersuites should be added and dropped. Is this simply a config change with testing, or does it require code to be written in one or more of the TLS stacks? Gerv -- 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 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote: * Can you provide some background or references on exactly how ciphersuite construction and choice works? Can I invent e.g. TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of elements? Can any combination be encoded in the ClientHello? Does the server support specific sets, or will it support my combination if it supports all the component pieces? No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. This is a design choice based on the fact that many crypto modules don't let you mix/match algorithms at will, and because you often can't/shouldn't move keys between crypto modules. * We should avoid leaking the distinction between mobile and desktop products in the TLS handshake, which means that the handshake should look the same on mobile and desktop. Why is this a goal? There are many, many other ways of determining this distinction, some supported by Mozilla (e.g. the UserAgent string). There is a difference between leaking to somebody on the network and leaking to the server you are connecting to. Remember that TLS hides the User-Agent string and other HTTP-level information is hidden from others on the network. So, if Firefox for Android and Firefox for Desktop use the exact same TLS handshaking logic/parameters, then it should be possible to make them indistinguishable from each other. The same question applies to your point about avoiding TLS fingerprinting. I think it should be a goal to make it hard to distinguish between specific instances of Firefox, but it seems to be not a goal to avoid people distinguishing between Firefox and IE, or Firefox for desktop and Firefox for Android. If every browser's TLS handshake were to look the same, then observers on the network wouldn't be able to tell browsers apart, though the website you are connecting to obviously would. I admit that is a state that is likely to be difficult to obtain. * this proposal does not recommend supporting the CBC-HMAC-SHA-2-based ciphersuites that those browsers recently added Can you spell out why? Is it because they don't offer forward secrecy? It is explained below. Worse performance, no security benefit, and they take up space in the handshake. * In the course of testing TLS 1.2 and the ALPN TLS extension, the Chromium team recently found that some servers choke when the ClientHello message in the TLS handshake is larger than 256 bytes. How many bytes are taken up per ciphersuite? How many can we probably fit in, if we say we need to include all the other stuff? They take two bytes per ciphersuite. If the 256-byte limitation cannot be worked around, then we basically can't afford to waste *any* bytes in the TLS handshake. It is already likely going to be very difficult for us to support the ALPN extension as it is, even after making these reductions. * Re: Camellia and SEED: we should talk to the organisations which pushed for their addition, and our business development people in the region, before eliminating them. (This is not to say that we will definitely not remove them if they raise objections.) Do you have suggestions for who to contact? * Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS. However, if we never use them, then have to switch to them because a problem arises with HMAC-SHA-1, how will they have received any testing? More generally, is there a place for including ciphersuites 'of the future', perhaps at lower priority, to try and make sure there aren't problems or interop issues with them? We will soon have AES-GCM and we'll hopefully soon have Salsa20/12+(Poly1305|UMAC|VMAC) to mitigate that. Relying on either/both of those alternatives kills more birds with fewer stones. I think ultimately we'd rather have all HMAC-based ciphersuites also marked deprecated, for performance and security reasons. * Your final section says what cipersuites should be added and dropped. Is this simply a config change with testing, or does it require code to be written in one or more of the TLS stacks? Dropping ciphersuites is a simple configuration change. In the top table, the notes column lists the ciphersuites that will require code changes to NSS and to SChannel. Bug 880543https://bugzilla.mozilla.org/show_bug.cgi?id=880543tracks the addition of AES-GCM ciphersuites to NSS's libssl. OpenSSL already implements them. I think Google may be working on Sals20/12+Poly1305 ciphersuites and there has been some small progress on adding Sals20/12 ciphersuites in the IETF TLS working group. Reordering ciphersuites in SChannel can be done with a configuration change to the app. Reordering ciphersuites in NSS either requires us to reorder
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Thoughts, as a random passerby: Of course I quite like the prioritization of (EC)DHE. I think standardizing on a ciphersuite preference order with the aims of reducing fingerprinting is a worthwhile (although wildly difficult) goal for SSL _libraries_, but less so for browsers - to the point of probably not being a fight worth fighting. A web browser is so incredibly complex it is next to impossible to browse with _soley_ over TLS, and the first HTTP request leaks the User Agent. Even with soley-over-TLS, requests for malware protection, the dynamic favorites RSS feeds Firefox bundles (which I quite hate), and the auto-update checks will leak the browser anyway. Trying to avoid leaking the preference to the network is admirable, and worthwhile in a library I think, but the browser is a mighty beast to tackle. There are lower hanging fruit than the TLS handshake right now. Weak DHE keys are a lurking problem. Someone needs to survey the internet. (Unless there's a paper I'm not aware of...) The Ephemeral ECDH certs is clever... but I feel like that's an awful amount of engineering for the relatively few organizations who their own Intermediate cert. Unless this is a strategic push to encourage Name Constraints. In which case: Hmm. Future work: A comprehensive profile for browsers' use of TLS. - In theory, this would be the domain of the relatively-new IETF PKI Operations Working Group, which is being driven by a few browser folks and many CA folks. I would suggest another item for Future Work and that is trying to work in protections against TLS downgrades. This has been batted around a few times in the past [0][1] but has never gained much traction or agreement. -tom [0] https://www.ietf.org/mail-archive/web/tls/current/msg08861.html [1] I'm failing to find a link, but Yoav had a trick he added to Opera to prevent downgrade if the server supported secure renegotiation. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
