Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx wrote: > But some people are also considering disabling it by default, > as I think all other where talking in this thread, not just > reduce the preference. > > > For the same reason, the server ciphersuite that we recommend at > > https://wiki.mozilla.org/Security/Server_Side_TLS > > does not drop Camellia, but lists it at the bottom of the ciphersuite. > > It's a safe choice, but not one that we recommend. > > As far as I know the reasons for not recommending it are: > - It's slower > - It probably doesn't have much constant-time implementations. > > So as I understand it, the reason for not recommending it don't > have anything to do with the security of Camellia itself. > Because of unfortunate design choices, Camellia is (along with AES) difficult to implement in constant time with high performance. That *is* a serious fault in the algorithm. AES-NI is a workaround for AES, but no such workaround exists for Camellia. In addition, Firefox supporting Camellia while other browsers don't is bad for interoperability. Finally, other browsers have demonstrated that Camellia isn't needed for web compatibility, so removing support for Camellia means we can avoid maintaining Camellia. Like I've said before, for any cipher that we support TLS_RSA_* for, we should be supporting some TLS_ECDHE_* variants, so that we don't make servers choose between the cipher they need/want to use and ephemeral key exchange. So, to keep Camellia support, we'd need to implement and enable the TLS_ECDHE_* variants. But, it doesn't seem worth the effort when it doesn't seem to improve interoperability, performance, or security. I think instead we are better off spending resources on making AES-GCM constant-time(-ish) and on adding support for ChaCha20+Poly1304. Google already has constant-time (I think) ChaCha20+Poly1304 patches for NSS and there's also been progress on constant-time(-ish) GHASH implementations for NSS. Note that ChaCha20+Poly1304, by design, is straightforward to implement in a high-speed, constant-time fashion. 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 Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote: > On 2013-12-15 11:13, Kurt Roeckx wrote: > >On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote: > >>On 2013-12-14 19:47, Kosuke Kaizuka wrote: > >>>Camellia is widely reviewed and chosen as a recommended cipher by > >>>several independent committees. > >>>If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also > >>>dropped. > >>> > >> > >>There is another reason to drop CAMELLIA: AES with AES-NI is 8 times > >>faster. AES-NI is supported by the majority of server CPUs right now. > >> > >>Camellia is still fast in software, my laptop computes between 90 and > >>160 MB/s with openssl and an intel cpu. But if we want to provide the > >>fastest response time to users, it's important to consider the server > >>cost on the client side. > > > >It's not because it's enabled that you have to use it. The > >priority of Camellia is now always below AES. If the server > >supports AES it should pick it. > > Right. And by "drop" I really meant "reduce preference of". Which is what we already did. As Brian's stats show, the reordering has already reduced Camellia's usage to about 0.03%. But some people are also considering disabling it by default, as I think all other where talking in this thread, not just reduce the preference. > For the same reason, the server ciphersuite that we recommend at > https://wiki.mozilla.org/Security/Server_Side_TLS > does not drop Camellia, but lists it at the bottom of the ciphersuite. > It's a safe choice, but not one that we recommend. As far as I know the reasons for not recommending it are: - It's slower - It probably doesn't have much constant-time implementations. So as I understand it, the reason for not recommending it don't have anything to do with the security of Camellia itself. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-15 11:13, Kurt Roeckx wrote: On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote: On 2013-12-14 19:47, Kosuke Kaizuka wrote: >Camellia is widely reviewed and chosen as a recommended cipher by >several independent committees. >If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also >dropped. > There is another reason to drop CAMELLIA: AES with AES-NI is 8 times faster. AES-NI is supported by the majority of server CPUs right now. Camellia is still fast in software, my laptop computes between 90 and 160 MB/s with openssl and an intel cpu. But if we want to provide the fastest response time to users, it's important to consider the server cost on the client side. It's not because it's enabled that you have to use it. The priority of Camellia is now always below AES. If the server supports AES it should pick it. Right. And by "drop" I really meant "reduce preference of". For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote: > On 2013-12-14 19:47, Kosuke Kaizuka wrote: > >Camellia is widely reviewed and chosen as a recommended cipher by > >several independent committees. > >If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also > >dropped. > > > > There is another reason to drop CAMELLIA: AES with AES-NI is 8 times > faster. AES-NI is supported by the majority of server CPUs right now. > > Camellia is still fast in software, my laptop computes between 90 and > 160 MB/s with openssl and an intel cpu. But if we want to provide the > fastest response time to users, it's important to consider the server > cost on the client side. It's not because it's enabled that you have to use it. The priority of Camellia is now always below AES. If the server supports AES it should pick it. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-14 19:47, Kosuke Kaizuka wrote: Camellia is widely reviewed and chosen as a recommended cipher by several independent committees. If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also dropped. There is another reason to drop CAMELLIA: AES with AES-NI is 8 times faster. AES-NI is supported by the majority of server CPUs right now. Camellia is still fast in software, my laptop computes between 90 and 160 MB/s with openssl and an intel cpu. But if we want to provide the fastest response time to users, it's important to consider the server cost on the client side. - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Longterm crypto support
On Sat, Dec 14, 2013 at 06:28:54PM -0800, Brian Smith wrote: > Kurt, > > Thanks for your suggestions. > > On Sat, Dec 14, 2013 at 12:46 PM, Kurt Roeckx wrote: > > > I think we need to come up with a plan to improve security in the > > long run. I think what we would like to see in general is: > > - Only SHA256 or better (and so TLS 1.2) > > > > This is gated almost purely on servers actually switching to SHA-2 certs > and TLS 1.2. See https://bugzilla.mozilla.org/show_bug.cgi?id=942515, which > is related to this. I think it makes sense to revisit this after we figure > out exactly what we're doing with SHA-1-based certificates, because it > doesn't make sense to plan to go "SHA-2 only" until that happens. I was thinking about microsoft's intention when proposing this, but I couldn't remember that their proposal was for 2017. I think their proposal only covers the certificates, while mine would cover everything including the MAC. The certificates are probably easier to do since you get to tell the CAs what you will allow. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Does Firefox overwrite the master password on exiting to prevent a cold boot attack?
Thanks for the detailed answer. > 1. my disk encryption keys I'm on ecrypfs so this should be fine. > 2. my OS user account passphrase Luckily they are hashed on my Linux system. > 3. my SSH keys > 4. my GPG keys As they are normally in the home directory they are protected by ecryptfs. So this makes at least my system most vulnerable by a cold boot attack. Just to go sure: As I know if security.ask_for_password is set to 1 Firefox will always ask for the master password. I'm assuming now Firefox does overwrite it in the memory too immediately after it was entered and Firefox could (not) find the needed username/password entries. Or am I wrong? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Longterm crypto support
On Sat, Dec 14, 2013 at 06:28:54PM -0800, Brian Smith wrote: > > - Only 2048 bit public, 128 bit symmetric, 256 bit elliptic, or > > better. > > > > Approximately 1.5% of Fx26 full handshakes that use RSA certs use keys > smaller than 2048 bits. So, enforcing the 2048 bit limit is not going to be > a simple thing to do for a while, even though we want to do it soon. SSL-pulse stats for 1024 bit keys (the rest is 2048 or 4096) - june: 5.4% (-0.7%) - july: 4.7% (-0.7%) - august: 4.1% (-0.6%) - september:3.3% (-0.8%) - october: 2.2% (-1.1%) - november: 1.7% (-0.5%) - december: 1.3% (-0.4%) If it continues at this rate, that would mean in about 2 months we should reach 0%, but it's probably going to take a little longer. > We can > enforce the 256 bit limit on ECC now though, because literally everybody > seems to be using the P-256 curve. (This actually makes me wonder if the > P-384 support even works, since not a single handshake in Firefox 26 used > it.) We only have 256 bit or higher. Openssl at least supports some 160 bit versions, but I see no good reason to add support for those. But I currently don't see why they don't get selected. I'm not sure if this has to do with SHA-384 not being available, but I doubt it. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sat, Dec 14, 2013 at 05:41:55PM -0800, Brian Smith wrote: > Fx26Fx27 Change Cipher Suite > 0.00% 14.15% +14.15% TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (new) > 0.00% 8.30% +8.30% TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (new) Are you sure you didn't switch those 2? At least your other mail with stats had them to other way around. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
Camellia is the only possible alternative cipher to AES in TLS. AES, Camellia: 128-bit or 256-bit key-size 3DES: 112-bit key-size SEED: 128-bit key-size, almost no usage outside South Korea (disabled by default in Firefox 27+) > little supported, never negotiated cipher One of the largest websites which support Camellia is Yahoo!. Firefox 26 or lower use TLS_RSA_WITH_CAMELLIA_256_CBC_SHA with Yahoo!. > not as well-tested & reviewed as AES ciphersuits Camellia is widely reviewed and chosen as a recommended cipher by several independent committees. If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also dropped. 1. NESSIE in 2003: https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf 2. CRYPTREC in 2013: http://www.cryptrec.go.jp/english/method.html 3. ENISA in 2013: https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report AES and Camellia are recommended for 128-bit block ciphers by these 3 committees. NESSIE says > The AES has been scrutinised by the U.S. National Institute of > Standards and Technology as a secure block cipher and adopted as a > U.S. Federal Information Processing Standard. Camellia has many > similarities to the AES, so much of the analysis for the AES is also > applicable to Camellia. It is also the case that the NESSIE project > did not find an attack on either the AES or Camellia. However, the > NESSIE partners, as well as the wider cryptographic community, have a > wide range of views about the AES and Camellia. Many NESSIE partners > have significant concerns that the simple algebraic structure of the > AES, and to a somewhat lesser extent Camellia, may lead to future > breakthroughs in the analysis of these block ciphers. CRYPTREC says > Camellia has been widely reviewed. > Unlike AES-192/256, related-key attack against Camellia is not reported. > Biclique attack to Camellia (with 2^128 Plaintext-Ciphertext pairs): > Camellia-128: 2^127.6, -192: 2^191.7, -256: 2^255.7 > (AES-128: 2^126.16 with 2^64 P-C pairs, 2^125.6 with 2^128 P-C pairs, -192: 2^189.74 with 2^80 P-C pairs, -256: 2^254.42 with 2^40 P-C pairs) (roughly summarized and translated from http://cryptrec.go.jp/report/c12_sch_web.pdf) ENISA says > The Camellia block cipher is used as one of the possible cipher > suites in TLS, and unlike AES is of a Feistel cipher design. Camellia > has a block length of 128 bits and supports 3 key lengths: 128, 192 > and 256 bits. The versions with a 192- or a 256-bit key are 33% > slower than the versions with a 128-bit key. > Observation: Just as for AES there is a relatively simple set of > algebraic equations which define the Camellia transform; this might > leave it open to algebraic attacks. However, just like AES such > attacks have not been shown to be effective. > we see that only the use of Camellia and AES are recommended within > a mode such as GCM or CCM. CAMELLIA_GCM for TLS has been already determined in RFC 6367. Bug for implementation of TLS_ECDHE_*_CAMELLIA_*_GCM to libssl is open (bug 940119). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
