Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[marlen...@hushmail.com]

I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in functionality.

I have read these proposed IETF drafts and am using them as guidance along with my experience:
https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
https://tools.ietf.org/html/draft-sheffer-tls-bcp-01

These are the default available ciphersuits in Firefox Aurora 28.0a2 on a Windows system:
C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
002F TLS_RSA_WITH_AES_128_CBC_SHA
0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA
0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5

Now follows reasoning for removing some of the ciphersuits.

Apache/nginx (and possibly many other) configurations that establish Perfect Forward Secrecy (PFS) ciphersuits will always have available a PFS ciphersuit that contains AES. This means that the following ciphersuits can be safely removed, also given their non-usage in real client-server connections:
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

Removing the above ciphersuits also helps avoiding some usage of 3DES (due to its low performance) and RC4 (due to its vulnerability).

DSS is obsolete and is not used for real client-server connections, hence the following ciphersuits can be removed:
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA

Camellia ciphersuits are little supported, never negotiated cipher, and not as well-tested & reviewed as AES ciphersuits. The following ciphersuits can be removed:
0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA

The last remaining 3DES ciphersuit should be removed for performance considerations and its legacy status:
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

The last remaining RC4 ciphersuits should be removed due to their vulnerability:
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5

RC4 ciphersuits will likely soon be prohibited anyway if the proposal is accepted https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01

Overall, this means that the following ciphersuits should be removed from the TLS handshake:
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5

This would bring the ciphersuit list down to:
C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
002F TLS_RSA_WITH_AES_128_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA

The positives of removing the listed ciphersuits:
1) It makes the TLS handshake smaller thus preventing some issues related to long handshake.
2) It protects users from misconfigured server ciphersuit preference order - and thus no vulnerable RC4 ciphersuits will be used.
3) It protects servers from misconfigured server ciphersuit preference order - and thus no performance hit will be incurred due to use of 3DES.
4) It prevents the use of little-reviewed Camellia ciphersuits.
5) It prevents the use of retired DSS.

The possible negatives of the removal:
1) Some client-server connections might fail.

Suggested mitigation of negatives:
If the initial handshake fails, make it a silent failure and retry with a handshake that contains a larger set of ciphersuits. This could also be accompanied with some non-blocking failure similar to how mixed-content warnings are presented to the user - and not show the full padlock icon in the addressbar.

Positives of this mitigation:
1) No client-server connections will fail (compared to the current state).

Negatives of mitigation:
1) Users are not as well protected against downgrade attacks as they could be - but this is probably the best we can do at the moment.

I have especially not heard anything similar to the suggested mitigation of the negatives of decreasing the number of available ciphersuits, so this might perhaps be a new idea how to move forward.

If you have any comments against the removal of a particular ciphersuit, please present a publicly accessible non-test webserver that only allows negotiation of the removed ciphersuits (and thus the client-server connection will fail).

I believe this proposal should be accepted, the ciphersuits removed, and the mitigation implemented in Firefox nightlies to gain more data on a larger userbase.

--
Marlene

[Brian Smith]

On Fri, Dec 13, 2013 at 10:48 PM, <marlen...@hushmail.com> wrote:

> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.

Hi,

Thank you for suggesting these changes, and thank you for posting your
message on the public mailing list. (I also appreciate the private email
you sent me on the subject.)

I will comment on your proposal again later. However, I want to share with
you some usage data from Firefox 28 Beta, that I think we will find helpful
in understanding what servers do. These numbers represent the cipher suite
chosen by the server for 4,011,451 real-life full handshakes in Firefox 28
beta.

First, here are the figures, sorted according to the order we offer the
cipher suite in the ClientHello:

Cipher Suite Count %
----------------------------------------------------------
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 567,486 14.15%
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786 8.30%
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 10,952 0.27%
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0 0.00%
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 19,472 0.49%
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0 0.00%
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0 0.00%
TLS_ECDHE_RSA_WITH_RC4_128_SHA 19,117 0.48%
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601 0.11%
TLS_DHE_RSA_WITH_AES_128_CBC_SHA 226,177 5.64%
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 44 0.00%
TLS_DHE_RSA_WITH_AES_256_CBC_SHA 23,319 0.58%
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 1,088 0.03%
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 557 0.01%
TLS_DHE_DSS_WITH_AES_128_CBC_SHA 9 0.00%
TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0 0.00%
TLS_RSA_WITH_AES_128_CBC_SHA 1,053,521 26.26%
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 18 0.00%
TLS_RSA_WITH_AES_256_CBC_SHA 36,203 0.90%
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0 0.00%
TLS_RSA_WITH_3DES_EDE_CBC_SHA 7,065 0.18%
TLS_RSA_WITH_RC4_128_SHA 1,507,191 37.57%
TLS_RSA_WITH_RC4_128_MD5 201,845 5.03%

Below are the same figures, sorted by frequency (most popular first). The
final column is an indication, of the cipher suites you suggest to remove,
whether I think this data offers strong evidence for the removal; "Remove-"
means "the data seems to contradict your recommendation," "Remove?" means
more study is needed, and "Remove+" means that the data supports your
conclusion.

Cipher Suite Count %
----------------------------------------------------------
TLS_RSA_WITH_RC4_128_SHA 1,507,191 37.57% Remove-
TLS_RSA_WITH_AES_128_CBC_SHA 1,053,521 26.26% Remove-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 567,486 14.15%
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786 8.30%
TLS_DHE_RSA_WITH_AES_128_CBC_SHA 226,177 5.64%
TLS_RSA_WITH_RC4_128_MD5 201,845 5.03%
TLS_RSA_WITH_AES_256_CBC_SHA 36,203 0.90%
TLS_DHE_RSA_WITH_AES_256_CBC_SHA 23,319 0.58%
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 19,472 0.49%
TLS_ECDHE_RSA_WITH_RC4_128_SHA 19,117 0.48% Remove?
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 10,952 0.27%
TLS_RSA_WITH_3DES_EDE_CBC_SHA 7,065 0.18% Remove-
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601 0.11% Remove?
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 1,088 0.03% Remove?
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 557 0.01% Remove?
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 44 0.00% Remove?
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 18 0.00% Remove?
TLS_DHE_DSS_WITH_AES_128_CBC_SHA 9 0.00% Remove?
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0 0.00%
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0 0.00%
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0 0.00% Remove+
TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0 0.00% Remove+
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0 0.00% Remove+

Your idea of offering a subset of cipher suites during the initial
handshake, and then falling back to another handshake later, requires more
discussion and more measurements to be done. I would like to do something
similar to what you suggest.

Note that my Remove+/?/- comments should not be taken as an acceptance or
rejection of your suggestions. I just want you to know my initial
impression, based on a quick look of the data.

Cheers,
Brian

[Brian Smith]

On Fri, Dec 13, 2013 at 11:51 PM, Brian Smith <br...@briansmith.org> wrote:

> I will comment on your proposal again later. However, I want to share with
> you some usage data from Firefox 28 Beta, that I think we will find helpful
> in understanding what servers do. These numbers represent the cipher suite
> chosen by the server for 4,011,451 real-life full handshakes in Firefox 28
> beta.
>

Above, I meant Firefox 27 beta.

Cheers,
Brian

[Kurt Roeckx]

On Sat, Dec 14, 2013 at 06:48:01AM +0000, marlen...@hushmail.com wrote:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in functionality.
>

> I have read these proposed IETF drafts and am using them as guidance along with my experience:
> https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
> https://tools.ietf.org/html/draft-sheffer-tls-bcp-01

I want to point out that we already had a very long discussion to
get to this point which is a compromise between what we want and
what the servers support.

Please note that apache and nginx are not the only servers out
there. I think that TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA is the
only (EC)DHE one supported my some IIS versions. On the other hand
I doubt anybody is going to bother with
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.

We currently have to live with RC4 since everybody suddenly seems
to want to use this.

> DSS is obsolete and is not used for real client-server connections, hence the following ciphersuits can be removed:
> 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA

I think this actually makes sense that we want to drop them at
some point. I would also like to move the minimum allowed bits
up. I think for DHE in NSS is currently happy with 512 bits, and
IIS is known to use 768 bits and apache 2.2 1024. I would like to
see a minimum of at least 1024 for them. I would like to have
this even higher, but I would like to see this changd to 768 for
DHE at least and 1024 for RSA/DSA/DSS.

> Camellia ciphersuits are little supported, never negotiated cipher, and not as well-tested & reviewed as AES ciphersuits. The following ciphersuits can be removed:
> 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
> 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA

But Camellia is the only suite other than AES that is recommended
to be used. Previous version of firefox even negiotatied
this often due to the order of the ciphers.

> The last remaining 3DES ciphersuit should be removed for performance considerations and its legacy status:
> 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

As you can see, there are sites still using it. They do not
support AES. So the question becomes do you want to use RC4
or 3DES?

> The last remaining RC4 ciphersuits should be removed due to their vulnerability:
> 0005 TLS_RSA_WITH_RC4_128_SHA
> 0004 TLS_RSA_WITH_RC4_128_MD5
>
> RC4 ciphersuits will likely soon be prohibited anyway if the proposal is accepted https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01

The SHA one is currently the most popular one, sometimes even the
only cipher that is enabled on some servers. Note that we also
put them completly at the end of our priority list and still is
used that much. But I think we all agree that we want to get rid
of it.

> The positives of removing the listed ciphersuits:
> 1) It makes the TLS handshake smaller thus preventing some issues related to long handshake.
> 2) It protects users from misconfigured server ciphersuit preference order - and thus no vulnerable RC4 ciphersuits will be used.
> 3) It protects servers from misconfigured server ciphersuit preference order - and thus no performance hit will be incurred due to use of 3DES.
> 4) It prevents the use of little-reviewed Camellia ciphersuits.
> 5) It prevents the use of retired DSS.
>
> The possible negatives of the removal:
> 1) Some client-server connections might fail.
>
> Suggested mitigation of negatives:
> If the initial handshake fails, make it a silent failure and retry with a handshake that contains a larger set of ciphersuits. This could also be accompanied with some non-blocking failure similar to how mixed-content warnings are presented to the user - and not show the full padlock icon in the addressbar.

I really see no point in this.


Kurt

[cl...@jhcloos.com]

Brian Smith <br...@briansmith.org> writes:

> Cipher Suite Count %
> ----------------------------------------------------------

> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786 8.30%
> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601 0.11%

Who issues ECDSA certs?

Is that intra-government usage?

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6

[falcon]

I believe startssl (even) will sign ecdsa certs if you send a csr for one, but this is of little utility without an ecdsa trust anchor.

Who issues ECDSA certs?

Is that intra-government usage?

--
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

[Brian Smith]

On Fri, Dec 13, 2013 at 10:48 PM, <marlen...@hushmail.com> wrote:

> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.
>
> I have read these proposed IETF drafts and am using them as guidance along
> with my experience:
> https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
> https://tools.ietf.org/html/draft-sheffer-tls-bcp-01
>

Besides those, you may find these interesting:
* My initial proposal (now out of date; I will clean it up):
https://briansmith.org/browser-ciphersuites-01.html
* Our previous recent discussion on this mailing list:

https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/gFfKw3EOffo
and
https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/IhrOqMZe8Go
and
https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/36na1B2brGU
and maybe more.

> These are the default available ciphersuits in Firefox Aurora 28.0a2 on a
> Windows system:
>

<some items snipped>


> C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
> 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA

> 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
> 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
>

Note that the cipher suites above were not agreed to in the previous
discussion and were not part of my proposal linked to above. They have been
enabled for a long time, and I did not disable them in Firefox 27 because I
wanted to be conservative in avoiding potential compatibility issues, and
because I wanted to see the measurements of the effects of the reordering
of the cipher suites. For reference, the cipher suite list for Firefox 26
appears at the end of this email.

> Apache/nginx (and possibly many other) configurations that establish
> Perfect Forward Secrecy (PFS) ciphersuits will always have available a PFS
> ciphersuit that contains AES. This means that the following ciphersuits can
> be safely removed, also given their non-usage in real client-server
> connections:
> C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>

I agree. The data shows that this cipher suite is never selected by servers
and it will be removed.


> C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
> C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
>

These cipher suites were included in my original proposal that we agreed
to. IMO, it does not make sense to remove these cipher suites unless we
also remove the TLS_RSA_WITH_RC4_128_* variants. Ephemeral key exchange +
RC4 is much better than RSA key exchange + RC4 (or even RSA key exchange +
AES) because it limits the damage of a compromised private key. The data
also shows that these cipher suites are still in use. I suspect that as
AES-GCM becomes more common, the use of these cipher suites will decrease
further and we can reconsider removing them. (More on RC4 below.)


> 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>

This cipher suite wasn't in my original proposal, however I think it makes
sense to retain it because it is used surprisingly often. Also, usually DHE
key exchange is better than RSA key exchange, unless the DHE key is very
small. Consequently, I won't remove this one yet, unless/until we come up
with a plan for small DHE keys.

> DSS is obsolete and is not used for real client-server connections, hence
> the following ciphersuits can be removed:
> 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
>

The data we have shows that these are almost never used, and when they are
used, they are always used with keys less than 2048 bits, which is supposed
to be the minimum key size we support, according to our CA policy. So, we
can try to remove these too.

Camellia ciphersuits are little supported, never negotiated cipher, and not
> as well-tested & reviewed as AES ciphersuits. The following ciphersuits can
> be removed:
> 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
> 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
>

I agree that we can remove the Camellia cipher suites now. With the new
cipher suite ordering, Camellia-256 usage dropped from ~5.55% in Firefox 26
beta to 0.03% in Firefox 27 beta. Also, Camellia-128 usage stayed at about
0% usage. If we have a problem with AES that causes Camellia to become more
important in the future, we can easily re-enable it by default with a
Firefox update.

> The last remaining 3DES ciphersuit should be removed for performance
> considerations and its legacy status:
> 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA
>

As Kurt noted, there are a lot of servers that support only 3DES and RC4.
If we remove the TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA and
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suites, we will increase the usage of
RC4. unless we disable RC4 at the same time. Also, I would bet that there
are now servers that can ONLY do 3DES, if they've disabled RC4 and only RC4
and 3DES were available. Also, 3DES is not the best (it has limitations
that arise from it being a 64-bit block cipher, and also it has bad
performance), but it is still considered a very secure cipher by almost
everybody. For these reasons, I think we should leave the these two cipher
suites enabled for now.

The last remaining RC4 ciphersuits should be removed due to their
> vulnerability:
> 0005 TLS_RSA_WITH_RC4_128_SHA
> 0004 TLS_RSA_WITH_RC4_128_MD5
>
> RC4 ciphersuits will likely soon be prohibited anyway if the proposal is
> accepted https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
>

I support this effort, but we probably cannot just turn of RC4 and walk
away. Instead, we would need to implement some compatibility measures like
Microsoft has done and like you suggested.

> The positives of removing the listed ciphersuits:
> 1) It makes the TLS handshake smaller thus preventing some issues related
> to long handshake.
>

During IETF88, we had a discussion about the long handshake issue. Xiaoyong
Wu from F5 described a workaround that Chrome has been testing and which
will be in NSS soon (bug 944157 [1]). So, it seems like the long handshake
issue may be solved.

> 2) It protects users from misconfigured server ciphersuit preference order
> - and thus no vulnerable RC4 ciphersuits will be used.
>

I hope I addressed this above. We can and should try something about this,
but we cannot simply turn off RC4.

> 3) It protects servers from misconfigured server ciphersuit preference
> order - and thus no performance hit will be incurred due to use of 3DES.
>

Around 1/10,000 servers seem to choose 3DES anyway, so I don't think this
is something to spend effort on.

> 4) It prevents the use of little-reviewed Camellia ciphersuits.
>

During my research, I found that Camellia has been studied more than I
originally gave it credit for. It definitely isn't just the Japanese
government being proud of a Japanese cipher. It is also part of ENISA
(European) cryptographic standards. However, because it is never used, and
because I suspect that all implementations that support Camellia also
support AES, and because other browsers do not support it, I agree that we
should remove it.

> 5) It prevents the use of retired DSS.
>

I agree that we should remove DSS cipher suites. We will have some
compatibility risk because other browsers currently have at least one DSS
cipher suite enabled. However, if browsers start enforcing the minimum key
size requirement of 2048 bits, then I believe the compatibility argument
will basically go away.

>
> The possible negatives of the removal:
> 1) Some client-server connections might fail.
>
> Suggested mitigation of negatives:
> If the initial handshake fails, make it a silent failure and retry with a

> handshake that contains a larger set of ciphersuites.


If somebody wants to work on this for RC4, I will help them out. I
recommend somebody take this on only if they have some experience writing
Gecko C++ code, though, because it is a little more complicated than simply
calling a few NSS functions. The code has to interact with Gecko's
preference service and deal with the fact that SSL happens on a thread
where the preference service is not available. I can point people to some
existing code that acts like a template. Otherwise, I think it will be
several weeks before I will be free to work on this part.

> This could also be accompanied with some non-blocking failure similar to
> how mixed-content warnings are presented to the user - and not show the
> full padlock icon in the addressbar.
>

UI changes are difficult because they require hours of meetings and hours
of email. Also, I don't think users will generally find such UI indicators
useful. Before we can bother the user with such things, we'd need to make
the use of sub-optimal crypto very small (e.g. by disabling RC4 in our
initial handshake like you suggested) first.

> I have especially not heard anything similar to the suggested mitigation
> of the negatives of decreasing the number of available ciphersuits, so this
> might perhaps be a new idea how to move forward.
>

I have been wanting to experiment with disabling RC4 and even RSA key
exchange cipher suites in the initial handshake for a while. Microsoft does
disable RC4 in the IE11 handshake (at least on Windows 8.1), so it seems
like that may be surprisingly reasonable, especially since use of the
TLS_ECDHE_*_WITH_RC4_128_SHA cipher suites has decreased to less than 0.5%
after we added TLS_ECDHE_*_WITH_AES_128_GCM_SHA256 cipher suites.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=944157

Firefox 26 cipher suite list:
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0087 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
C00F TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
C005 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0044 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
C00E TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
C00C TLS_ECDH_RSA_WITH_RC4_128_SHA
C004 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
C002 TLS_ECDH_ECDSA_WITH_RC4_128_SHA
0096 TLS_RSA_WITH_SEED_CBC_SHA
0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
002F TLS_RSA_WITH_AES_128_CBC_SHA
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5
C008 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
C00D TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
C003 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
FEFF SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

Cheers,
Brian

[Brian Smith]

On Sat, Dec 14, 2013 at 2:13 PM, falcon <fal...@iridiumlinux.org> wrote:

> I believe startssl (even) will sign ecdsa certs if you send a csr for one,
> but this is of little utility without an ecdsa trust anchor.
>
> -------- Original message --------
> From: cl...@jhcloos.com
>

> Brian Smith <br...@briansmith.org> writes:
> > Cipher Suite Count %
> > ----------------------------------------------------------
> > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786 8.30%
> > TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601 0.11%
>
> Who issues ECDSA certs?
>
> Is that intra-government usage?
>

Several CAs in Mozilla's CA program are now offering ECDSA certificates.

Some older versions of TLS had a requirement that all certificates in the
cert chain must be signed using the same type of key. However, NSS has
never enforced that and AFAICT most other implementations haven't either.
However, some CAs won't sign ECDSA certificates with their RSA certificates
for reasons that are better described by them than me.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Kurt Roeckx]

On Sat, Dec 14, 2013 at 03:36:44PM -0800, Brian Smith wrote:
>
> Note that the cipher suites above were not agreed to in the previous
> discussion and were not part of my proposal linked to above. They have been
> enabled for a long time, and I did not disable them in Firefox 27 because I
> wanted to be conservative in avoiding potential compatibility issues, and
> because I wanted to see the measurements of the effects of the reordering
> of the cipher suites. For reference, the cipher suite list for Firefox 26
> appears at the end of this email.

I assume that 27 when it's released will get the list from your
other mail, and so for intsance removes all the ECDH ciphers?


Kurt

[Brian Smith]

The current list for Firefox 27 beta is:

C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
002F TLS_RSA_WITH_AES_128_CBC_SHA
0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA
0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5

Next week, the following changes will be made:

1. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA will be disabled
2. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA will be moved to the third spot,
ahead of TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, due to
https://bugzilla.mozilla.org/show_bug.cgi?id=946147.

There may be more changes during Firefox 27 beta if we find more
compatibility issues. It is also possible that TLS 1.2 and/or AES-GCM
cipher suites could still get disabled before 27 is released, though we're
trying to make sure that doesn't happen.

Cheers,
Brian

[Kosuke Kaizuka]

Camellia is the only possible alternative cipher to AES in TLS.

> 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).

[Brian Smith]

On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka <cai....@gmail.com> wrote:

> > 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!.
>

In Firefox 27 or later, Yahoo! will choose TLS_RSA_WITH_AES_128_CBC_SHA
instead, because of the cipher suite order change in Firefox 27.

In case people are curious how the cipher suite order has changed servers'
selection of cipher suites between Firefox 26 beta and Firefox 27 beta,
here is a table:

Fx26 Fx27 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)
0.74% 0.27% -0.47% TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
0.00% 0.00% - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
1.97% 0.49% -1.48% TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
0.00% 0.00% - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
0.00% 0.00% - TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
10.22% 0.48% -9.74% TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
6.75% 0.11% -6.64% TLS_ECDHE_RSA_WITH_RC4_128_SHA
0.89% 5.64% +4.75% TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0.00% 0.00% - TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
2.66% 0.58% -2.08% TLS_DHE_RSA_WITH_AES_256_CBC_SHA
2.38% 0.03% -2.35% TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0.00% 0.01% +0.01% TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0.00% 0.00% - TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0.00% 0.00% - TLS_DHE_DSS_WITH_AES_256_CBC_SHA
3.77% 26.26% +22.50% TLS_RSA_WITH_AES_128_CBC_SHA
0.00% 0.00% - TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
21.40% 0.90% -20.50% TLS_RSA_WITH_AES_256_CBC_SHA
3.18% 0.00% -3.18% TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
0.00% 0.00% - TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (removed)
0.04% 0.18% +0.13% TLS_RSA_WITH_3DES_EDE_CBC_SHA
0.00% 0.00% - TLS_RSA_WITH_SEED_CBC_SHA (removed)
41.17% 37.57% -3.60% TLS_RSA_WITH_RC4_128_SHA
4.83% 5.03% +0.21% TLS_RSA_WITH_RC4_128_MD5

Interestingly:

* AES-128 has largely replaced AES-256 because AES-128 was moved ahead of
AES-256.
* AES-GCM has largely replaced RC4 amongst sites doing ECDHE key exchange.
* Camellia usage dropped from >5% to close to 0% because AES cipher suites
were moved ahead of their corresponding Camellia cipher suites.
* Virtually no site was using SEED.
* There was a ~4% increase in ephemeral key exchange usage, almost all of
which was due to increased adoption of ECDHE.

[Kosuke Kaizuka]

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!.

[Kurt Roeckx]

On Sat, Dec 14, 2013 at 05:41:55PM -0800, Brian Smith wrote:
> Fx26 Fx27 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

[Julien Vehent]

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

[Kurt Roeckx]

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

[Julien Vehent]

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

[Kurt Roeckx]

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

[Brian Smith]

On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx <ku...@roeckx.be> 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.

[Kurt Roeckx]

On Sun, Dec 15, 2013 at 09:50:04PM -0800, Brian Smith wrote:
>
> so removing support for Camellia means we can avoid maintaining Camellia.

I was under the impression that you wanted to keep it in NSS, just
not enabled by default. I can perfectly understand that, I'm
neither in favour or against changing that default. But I think
removing support for it is a step too far, since we might at some
point need it.

> 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'm not sure how hard adding an ECDHE version is, but I can't
imagine it being that hard.

> 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.

ChaCha20+Poly1305 (not 1304) looks very promising, but I'm not
sure how much research has gone into ChaCha20. It seems like
a good candidate, since the related Salsa20 at least has had
some research.

But I wouldn't remove Camellia until at least something like
ChaCha20+Poly1305 has been used for a while.


Kurt

[Kurt Roeckx]

On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote:

> 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.

You might also want to read:
https://bettercrypto.org/


Kurt

[Julien Vehent]

[cc-ing the cert.at mailing list that published this guide]

Thanks for the link! I wasn't aware of this guide.

Overall, I think this guide is great! The configuration examples are very
useful.
It's also good to have multiple TLS guides with different audiences, so I'm
definitely
glad to see more people take on the issue.

I need to do a thorough read of the entire thing. I am a bit puzzled by some
of the
choices made around their ciphersuite "B" (the most realistic and practical
one). Most
of the ciphersuite construction sections are still empty, so it's hard to
understand
what exactly is intended. I did notice a few things that I, personally, find
arguable:

Why prefer DHE to ECDHE, when the former is 3 times slower than the later?
There is a bit of a justification in 3.5:
"Since there is much discussion on the security of ECC, flawed settings
might very
well compromise the security of the entire system."
I wish there was references to these "discussions". My understanding of the
state of
the art of ECC is that P-256 is considered at least as secure as DH and RSA.

They recommend AES-128 in "3.4. Keylengths", but publish a ciphersuite that
prefers
AES-256 (see below). This is probably just an oversight, the guide is still
in "Draft".

The guide is not backward compatible with all clients. We, at Mozilla, must
maintain
backward compatibility with even the oldest, most broken, clients on the
internet, and
this shapes our guidelines. For example, the ciphersuite B doesn't contain
3DES or RC4,
and is therefore unusable on *a lot* of PC that still run Windows XP. I wish
we could
just remove these two ciphers, but it's not a realistic goal in the near
future.

Same goes for the recommendation to use DH parameters > 1024 bits. We tried
using a 2048
bits parameter a few months back. We first noticed a big spike in CPU usage,
caused by
the largest exponentiation, but that was still acceptable. What forced the
rollback is
the long list of java 6 clients that broke, because they don't accept DH
keys > 1024 bits.
Until all of these clients get fixed, DH params will be limited to 1024
bits.

I *think* they want to prefer CAMELLIA to AES, judging by the published
ciphersuite.
But the construction must be wrong because it returns AES first. If the
intent is to
prefer Camellia, then I am most interesting in the rationale.

ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and
makes the
ciphersuite portable to systems that prefer ECDSA certicates (granted, it's
not that many...).

$ openssl ciphers -v
'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'|column
-t
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA256
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256)
Mac=SHA384
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128)
Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA256
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA1
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256)
Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128)
Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128)
Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256)
Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256)
Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128)
Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128)
Mac=SHA1

--
Julien Vehent
OpSec @ Mozilla

[Kurt Roeckx]

On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
> > I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite.
> > But the construction must be wrong because it returns AES first. If the intent is to
> > prefer Camellia, then I am most interesting in the rationale.

> Thanks for reporting this!
>
> Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody
> is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the
> same security.

I know that for AES people having been putting an effort in making
this constant time. Having AES-NI clearly helps with this. I
can't say the same for Camellia and so think it doesn't make sense
to prefer it over AES.

NSS/Firefox currently still has Camellia as first non-ECDHE and
as result does use it for sites supporting it. But as far as I
know it's the only browser supporting it, and the next version is
going to prefer AES over Camellia all the time which resulted in
it's usage going from about 5% to as good as 0%.

There has also been talk about either disbaling it by default
or even dropping support for it but that currently didn't happen
yet.


Kurt

[Kurt Roeckx]

On Thu, Jan 02, 2014 at 10:10:49PM +0100, Aaron Zauner wrote:
>
> What's the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way?

Not being part of the mozilla team myself, I at least have the
impression that they want it. You might want to look at this
old version:
https://briansmith.org/browser-ciphersuites-01.html

Lots has been discussed and changed since that, but it at least
mentions it.

Google is also working on getting it into NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=917571


Kurt

[Julien Vehent]

Hi Aaron,

On 2014-01-02 16:10, Aaron Zauner wrote:
> Hi Kurt,

>
> On 02 Jan 2014, at 21:51, Kurt Roeckx <ku...@roeckx.be> wrote:
>
>> On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
>>>> I *think* they want to prefer CAMELLIA to AES, judging by the
>>>> published ciphersuite.
>>>> But the construction must be wrong because it returns AES first.
>>>> If the intent is to
>>>> prefer Camellia, then I am most interesting in the rationale.
>>> Thanks for reporting this!
>>>
>>> Yes. The intent was to prefer Camellia where possible. First off we
>>> wanted to have more diversity. Second not everybody
>>> is running a sandybridge (or newer) processor. Camellia has better
>>> performance for non-intel processors with about the
>>> same security.

I would argue that our documents target server configurations, where
AES-NI is now a standard.

>
> What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec.
> Team by the way?

There are 5 security teams at Mozilla, so Mozilla Sec Team is a very
large group.
I think we all want a new stream cipher in TLS to replace RC4. But
that's going
to take years, and won't help the millions of people who don't replace
their software
that often.

From an Operations Security point of view, the question is: how do we
provide the
best security possible, with the cards we currently have in our hands,
and without
discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the
short term.

- Julien

[Julien Vehent]

Hi Aaron,

Two things I'd like to mention before I reply:

1. I think it's great to have two guides with divergent points of view.
I'm mostly
interested in discussing design choices, because these discussions
are useful.
I'm not interested in convincing the ACH group that one
recommendation is better
than the other, since it completely depends on the context.

2. My experience as a web hosting engineer, and sysadmin, has convinced
me that
building security recommendations on what academia thinks alone is
very dangerous.
Security doesn't live in a bubble. It depends on people and systems.
It must
protect an activity, but never ever block it entirely.

That being said, I put my comments below.

On 2014-01-02 15:33, Aaron Zauner wrote:
> On 02 Jan 2014, at 18:09, Julien Vehent <jul...@linuxwall.info>

> wrote:
>> Why prefer DHE to ECDHE, when the former is 3 times slower than the
>> later?
>> There is a bit of a justification in 3.5:
>> "Since there is much discussion on the security of ECC, flawed
>> settings might very
>> well compromise the security of the entire system."
>> I wish there was references to these "discussions". My understanding
>> of the state of
>> the art of ECC is that P-256 is considered at least as secure as DH
>> and RSA.

> Well, no. Bernstein and Lange have been auditing NIST/SECG and other
> standardized curves that are
> currently implemented in crypto libraries over the last years. They
> may be considered secure against
> the ECDLP (some) but other issues remain that caused us to prefer DHe
> over ECDHe.
> We’re aware of the performance implications - the paper in general
> tries to cope with best performance
> and backwards compatability, but not at the cost of security. I’m
> aware that this philosophy might differ
> to that of the Mozilla Security Team. Recent publications have
> prompted some change in mindset though
> and one cannot recommend a security guide that takes all factors into
> consideration at the potential cost
> of (side channel) attacks or downgrade attacks.
>
> Please take the time to read up on:
> - http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
> - http://safecurves.cr.yp.to/
> -
>
> http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters
>
> (There’s also interesting research to Koblitz curves in the reply by
> thomas pornin)
>

I will bail here. My understanding of the mathematics of ECC isn't
sufficient to make
a strong decisions. Others at Mozilla, Google and major organizations
have decided
to implement ECC, and we trust their decision.

From my end, the decision to prefer ECC to DHE in Mozilla's guidelines
is performance oriented.

>>
>> They recommend AES-128 in "3.4. Keylengths", but publish a
>> ciphersuite that prefers
>> AES-256 (see below). This is probably just an oversight, the guide
>> is still in "Draft”.

> Our viewpoint was that if possible, take a stronger cipher. We’re
> aware that people might want
> to change this in their configuration if performance is paramount. We
> probably should discuss this again.
>

Aside from performance, timing attacks are apparently easier in
AES-256.
https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ

>> The guide is not backward compatible with all clients. We, at
>> Mozilla, must maintain
>> backward compatibility with even the oldest, most broken, clients on
>> the internet, and
>> this shapes our guidelines. For example, the ciphersuite B doesn't
>> contain 3DES or RC4,
>> and is therefore unusable on *a lot* of PC that still run Windows
>> XP. I wish we could
>> just remove these two ciphers, but it's not a realistic goal in the
>> near future.

> I personally think this is the wrong descision. I’m aware that you
> want to cater to as many clients as possible,
> but you also want to ship a solid and secure product. What people see
> and care about when they surf from
> XP machines using RC4 or 3DES is this nice green padlock in the
> browser bar. What they actually get as
> security are ciphers that have been considered insecure in academia
> for now over 15 years.
>

3DES isn't broken.
RC4 is broken, but I am yet to see a practical attack that doesn't
require gigabits of traffic.
Again, this is the tradeoff between what academia thinks is secure, and
the level of security
users need. It's more important for us to allow Chinese users to
download Firefox, than it is
to disable RC4 (that westerners almost never use anyway).

>> Same goes for the recommendation to use DH parameters > 1024 bits.
>> We tried using a 2048
>> bits parameter a few months back. We first noticed a big spike in
>> CPU usage, caused by
>> the largest exponentiation, but that was still acceptable. What
>> forced the rollback is
>> the long list of java 6 clients that broke, because they don't
>> accept DH keys > 1024 bits.
>> Until all of these clients get fixed, DH params will be limited to
>> 1024 bits.

> As far as I know stronger DH params are supported by the Java Crypto
> Extensions package. That said
> it’s usually not deployed anywhere. We’re aware of the issue but
> using DH parameters of 1024 bits only
> can provide security that is slightly less than 1024bit RSA which can
> certainly be factored by large agencies.
> - It takes you about 48hours to factor 512bit RSA keys in EC2:
> http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
> - The largest Key factored by public research (in a small university
> setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006
>
> We hope that Java will adopt a reasonable security policy in the
> future, although I’m personally not conviced that they will.
>

For us, it's a choice between DHE with 1024, or no DHE at all. We will
not block a subgroup
of users because they don't support larger keys. And I suspect no
business ever will.

So, on DHE vs !DHE, here's the rationale:

RSA key rotations happen very rarely in hosting environments. Except
when the CA requires it,
it's not uncommon to see private keys that are several years old. Keys
also move very easily,
end up in people's mailboxes or shared folders, or get stored in cloud
providers that don't
zero their disks after use.

From an operational perspective, the risk of leaking a RSA private key
is many times higher than
the risk of factoring a DHE key exchange. Even if this key exchange
uses half the key size of the
RSA key.

If an organization wants to spy on Mozilla's DHE traffic, they need to
factor *every single key exchange*.
On a normal day, that's hundreds of thousands of them. I'm quite
certain that the biggest security
agencies have clusters than can factor a 1024 DHE key within minutes,
but it's still a lot harder
and more targeted than factoring one single 2048 RSA key that is used
for 5 years.

For this reason, we recommend DHE with 1024 bits parameters, and RSA
2048 keys for authentication.

>> I *think* they want to prefer CAMELLIA to AES, judging by the
>> published ciphersuite.
>> But the construction must be wrong because it returns AES first. If
>> the intent is to
>> prefer Camellia, then I am most interesting in the rationale.
> Thanks for reporting this!
>
> Yes. The intent was to prefer Camellia where possible. First off we
> wanted to have more diversity. Second not everybody
> is running a sandybridge (or newer) processor. Camellia has better
> performance for non-intel processors with about the

> same security. We hope the IETF TLS-WG will chose to adopt the
> proposal by Adam Langley of Google to include the
> ChaCha20 stream cipher and Poly1305 MAC to TLS. It’s already
> implemented in Chrome. It’ll provide for better security
> with lower performance overhead and more diversity for users with
> non-Intel processors.
>
> http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00
>
> Is there a good reason not to prefer Camellia over AES? The issue is,
> if it’s not prefered it won’t get used in any type of
> machine as it’s set up because all clients will end up using AES due
> to the way the ciphersuite is implemented.

>
>> ECDSA is explicitely discarded. It doesn't hurt to have it enabled,
>> and makes the
>> ciphersuite portable to systems that prefer ECDSA certicates

>> (granted, it's not that many…).
> Agreed. And we will as soon as a TLS standard supports other Curves
> as well. Don’t get me wrong; ECC is a cool thing and very
> good for security with relatively low performance overhead as
> compared to RSA - But it’s also quite new in terms of implementation
> in libraries and security audits. With the research I refered to
> above I’d feel more safe to remove ECDSA for now.
>
> Thanks,
> Aaron

- Julien

[Ryan Sleevi]

On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:
> Hi Aaron,
>
> On 2014-01-02 16:10, Aaron Zauner wrote:
> > Hi Kurt,
> >
> > On 02 Jan 2014, at 21:51, Kurt Roeckx <ku...@roeckx.be> wrote:
> >
> >> On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:

> >>>> I *think* they want to prefer CAMELLIA to AES, judging by the
> >>>> published ciphersuite.
> >>>> But the construction must be wrong because it returns AES first.
> >>>> If the intent is to
> >>>> prefer Camellia, then I am most interesting in the rationale.
> >>> Thanks for reporting this!
> >>>
> >>> Yes. The intent was to prefer Camellia where possible. First off we
> >>> wanted to have more diversity. Second not everybody
> >>> is running a sandybridge (or newer) processor. Camellia has better
> >>> performance for non-intel processors with about the
> >>> same security.
>

> I would argue that our documents target server configurations, where
> AES-NI is now a standard.

I would have to disagree here. The two largest users of NSS, by *any*
measure, are Firefox and Chromium, both of which use it as a client.
Further, the notion of "server" configurations is further muddied by
efforts such as WebRTC, which sees a traditional "client" (eg:
heterogeneous configurations and architectures) acting as both a DTLS
client and a DTLS server.

NSS in server mode is so full of sharp edges and so few code examples that
I'd strongly discourage it being used as the reference for what NSS
"SHOULD" do.

>
> >
> > What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec.

> > Team by the way?
>
> There are 5 security teams at Mozilla, so Mozilla Sec Team is a very
> large group.
> I think we all want a new stream cipher in TLS to replace RC4. But
> that's going
> to take years, and won't help the millions of people who don't replace
> their software
> that often.

Really? If anything, Firefox and Chromium have shown that new changes can
be deployed on the order of weeks-to-months, and with server opt-in (such
as NPN/ALPN), the majority of *users* traffic can be protected or enhanced
within a few weeks-to-months after.

Google already has deployed experimental support, for example. Likewise,
the adoption of SPDY - within Firefox and within a number of significant
web properties - show that it's significantly quicker than it used to be
to protect users.

You're correct that there's going to be a long-tail of sites that don't
update, sure, but rapid deployment is certainly an increasing possibility
for the majority of users.

>
> From an Operations Security point of view, the question is: how do we
> provide the
> best security possible, with the cards we currently have in our hands,
> and without
> discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the
> short term.
>
> - Julien

I strongly, vehemently disagree with that conclusion. Solutions like
ChaCha20/Poly1305 are able to reach a broad spectrum of users near
immediately and ubiquitously, providing meaningful security and speed
improvements to users. If the idea is that no solution is a good solution
until it's a ubiquitous solution, well, that's just silly and not
reflective of the world we live in at all.

[Julien Vehent]

Sorry for the confusion. By "our documents", I meant:
* https://wiki.mozilla.org/Security/Server_Side_TLS
* https://bettercrypto.org/

And not NSS in client mode.

Your point about WebRTC making the client a server is interesting
though.
Which ciphers preferences will the server use ?

There is the case of old clients that don't upgrade, and the case of
servers.

The reality on the server side isn't that bright, I'm afraid. Upgrading
server components is still slow and difficult. I've been trying to find
commercial systems that support the full blend of TLS features, and
failed.

Chances are that even if new ciphers make it into TLS1.3, they won't be
widely deployed in any production environment for another 3 to 5 years.
After all, TLS 1.2 was standardized in 2008, and we're just starting to
see it.

>>
>> From an Operations Security point of view, the question is: how do
>> we
>> provide the
>> best security possible, with the cards we currently have in our
>> hands,
>> and without
>> discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in
>> the
>> short term.
>>
>> - Julien
>
> I strongly, vehemently disagree with that conclusion. Solutions like
> ChaCha20/Poly1305 are able to reach a broad spectrum of users near
> immediately and ubiquitously, providing meaningful security and speed
> improvements to users. If the idea is that no solution is a good
> solution
> until it's a ubiquitous solution, well, that's just silly and not
> reflective of the world we live in at all.
>

That is not what I meant. I simply wanted to point out that, on the
operational
side, changes and improvements are *a lot* slower to propagate.
Even if ChaCha2020/Poly1305 are deployed in Firefox and Chrome
tomorrow, we won't
have them on the server side for a while. And when we do, there will
still be a lot
of users who don't use it. Look at the percentage of users who
negotiate ECDHE with
AES-GCM, for example.

Don't get me wrong: it's a critical improvement to make. But in the
meantime,
we still need to find the best security trade offs for the remaining
80%. And, sadly,
for some people, that means using RC4 or 3DES.

- Julien

[Julien Vehent]

[Kurt Roeckx]

On Thu, Jan 02, 2014 at 02:12:47PM -0800, Ryan Sleevi wrote:
> > > What's the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec.

> > > Team by the way?
> >
> > There are 5 security teams at Mozilla, so Mozilla Sec Team is a very
> > large group.
> > I think we all want a new stream cipher in TLS to replace RC4. But
> > that's going
> > to take years, and won't help the millions of people who don't replace
> > their software
> > that often.
>
> Really? If anything, Firefox and Chromium have shown that new changes can
> be deployed on the order of weeks-to-months, and with server opt-in (such
> as NPN/ALPN), the majority of *users* traffic can be protected or enhanced
> within a few weeks-to-months after.
>
> Google already has deployed experimental support, for example. Likewise,
> the adoption of SPDY - within Firefox and within a number of significant
> web properties - show that it's significantly quicker than it used to be
> to protect users.
>
> You're correct that there's going to be a long-tail of sites that don't
> update, sure, but rapid deployment is certainly an increasing possibility
> for the majority of users.

Updates on the client side can be done in a few months, at least
for a very large population of the clients. But things tend to
break in unexpected ways making and it ussually takes a lot of
testing time before it can really be deployed.

But I see more problems getting the server side to change. Maybe
you can convice some people to disable certain things, but I think
it's going to be hard to try to convice them that they should
upgrade to a new software version. I've tried and failed.

When firefox 27 is released all major browsers will finally
support TLS 1.1+ in their latest version. But on the server
side we now see about 20% that support it, which is an increase
of about 15% over last year. We also still see 25% that still
supports SSLv2. At this rate it's still going to take years
before you can say that the majority of the sites will support
it.

I think we should find a way to force them to upgrade, and
trying to be as compatible as possible isn't really helping.


Kurt

[ianG]

On 3/01/14 01:06 AM, Julien Vehent wrote:


> 3DES isn't broken.


No, but it is end of life. 112bit security for the 2key variant, and an
8 byte block makes it just old. If you've got AES there, use it. Who
hasn't got it?

> RC4 is broken, but I am yet to see a practical attack that doesn't
> require gigabits of traffic.

What is a real concern is RC4. Anything done to move away from that has
to be a good thing. The recent talk by DJB has some real fun
descriptions of just how crappy it is becoming.

http://financialcryptography.com/mt/archives/001461.html

The way I read it, trouble starts at 2^24, that's 16M. By the time you
get to 2^30 or 1G it's all over... Caveat -- I'm working from the
graphs described from p49 of the talk, I don't pretend to understand
them other than what the pictures say.

> Again, this is the tradeoff between what academia thinks is secure, and
> the level of security
> users need. It's more important for us to allow Chinese users to
> download Firefox, than it is
> to disable RC4 (that westerners almost never use anyway).

Hmmm.. Are the Chinese blocked from stronger crypto?

>>> Same goes for the recommendation to use DH parameters > 1024 bits. We
>>> tried using a 2048
>>> bits parameter a few months back. We first noticed a big spike in CPU
>>> usage, caused by
>>> the largest exponentiation, but that was still acceptable. What
>>> forced the rollback is
>>> the long list of java 6 clients that broke, because they don't accept
>>> DH keys > 1024 bits.

Java 6 is covered in mud all over, crypto wise. Maybe time for some
nasty words to start circulating.

>>> Until all of these clients get fixed, DH params will be limited to
>>> 1024 bits.
>> As far as I know stronger DH params are supported by the Java Crypto
>> Extensions package. That said
>> it’s usually not deployed anywhere. We’re aware of the issue but
>> using DH parameters of 1024 bits only
>> can provide security that is slightly less than 1024bit RSA which can
>> certainly be factored by large agencies.
>> - It takes you about 48hours to factor 512bit RSA keys in EC2:
>> http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
>> - The largest Key factored by public research (in a small university
>> setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006
>>
>> We hope that Java will adopt a reasonable security policy in the
>> future, although I’m personally not conviced that they will.

Problem here is that it isn't so much 'Java' it's more the platforms.
Android is stuck on Java 6, and the JCE choices aren't even that modern.

http://financialcryptography.com/mt/archives/001450.html

Mac OSX has now bailed from Java directly, so one gets it from
Oracle/sun directly, which means Java 7.

I agree with that.

>>> I *think* they want to prefer CAMELLIA to AES, judging by the
>>> published ciphersuite.
>>> But the construction must be wrong because it returns AES first. If
>>> the intent is to
>>> prefer Camellia, then I am most interesting in the rationale.
>> Thanks for reporting this!
>>
>> Yes. The intent was to prefer Camellia where possible. First off we
>> wanted to have more diversity.

AS I've argued before, diversity as an argument seems not to survive in
the practical world. But that's something that is contrarian, although
it is becoming more mainstream.




iang

[Julien Vehent]

On 2014-01-02 18:59, ianG wrote:
> On 3/01/14 01:06 AM, Julien Vehent wrote:
>
>
>> 3DES isn't broken.
>
>
> No, but it is end of life. 112bit security for the 2key variant, and an 8
> byte block makes it just old. If you've got AES there, use it. Who hasn't
> got it?

See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
"Internet Explorer uses the cryptographic library “schannel”, which is OS
dependent. schannel supports AES in Windows Vista, but not in Windows XP."

>
>
>> RC4 is broken, but I am yet to see a practical attack that doesn't
>> require gigabits of traffic.
>
>
> What is a real concern is RC4. Anything done to move away from that has
> to be a good thing. The recent talk by DJB has some real fun descriptions
> of just how crappy it is becoming.
>
> http://financialcryptography.com/mt/archives/001461.html
>
> The way I read it, trouble starts at 2^24, that's 16M. By the time you
> get to 2^30 or 1G it's all over... Caveat -- I'm working from the graphs
> described from p49 of the talk, I don't pretend to understand them other
> than what the pictures say.
>
>
>> Again, this is the tradeoff between what academia thinks is secure, and
>> the level of security
>> users need. It's more important for us to allow Chinese users to
>> download Firefox, than it is
>> to disable RC4 (that westerners almost never use anyway).
>
>
> Hmmm.. Are the Chinese blocked from stronger crypto?
>
>

According to http://www.modern.ie/ie6countdown:
* 22.2% of China uses IE6
* 4.9% of users worlwide use IE6

I believe that our jobs, as security professionals, is to provide the best
security to everyone. Not only to the people that have a better access to
technology.
This is consistent with Mozilla's mission. So we won't disable old crypto
algorithms because the security community admits that they are bad. We have
to live with them.

Again, site owners are free to make their own decisions. This isn't an
unbreakable rule. At Mozilla, for example, the persona websites are unusable
with old browsers anyway, so it makes sense to enable stronger TLS on that
one specifically.

[ianG]

On 3/01/14 19:24 PM, Julien Vehent wrote:
> On 2014-01-02 18:59, ianG wrote:
>> On 3/01/14 01:06 AM, Julien Vehent wrote:
>>
>>
>>> 3DES isn't broken.
>>
>>
>> No, but it is end of life. 112bit security for the 2key variant, and
>> an 8 byte block makes it just old. If you've got AES there, use it.
>> Who hasn't got it?
>
> See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
> "Internet Explorer uses the cryptographic library “schannel”, which is
> OS dependent. schannel supports AES in Windows Vista, but not in Windows
> XP."

Right, Windows XP. Which is end of life.

>> Hmmm.. Are the Chinese blocked from stronger crypto?
>
> According to http://www.modern.ie/ie6countdown:
> * 22.2% of China uses IE6
> * 4.9% of users worlwide use IE6

Thanks for that! More end of life. And DJB says it's worse, we've
retrograded to about 50% RC4 usage.

> I believe that our jobs, as security professionals, is to provide the
> best security to everyone.

That is mozilla's mission. It provides its products to everyone. Which
naturally means it cannot and does not provide the 'best security' to
every person, rather it provides the best 'security for everyone'.

Different story -- one moves security up, at the expense of users, the
other keeps users happy, but puts security on a race to the bottom.

> Not only to the people that have a better
> access to technology.
> This is consistent with Mozilla's mission.

Absolutely! I'm well familiar of how the monolith of Mozilla's mission
casts a shadow over security.

BetterCrypto however is seeking ... *better crypto*. And that is a
different goal. Different users, different tradeoffs.

Where the two groups part company is on bad crypto. If IE6 and XP users
have bad crypto, then BetterCrypto is not for them.

> So we won't disable old
> crypto algorithms because the security community admits that they are
> bad. We have to live with them.

Sure. And to some extent I don't disagree -- K6 speaks to ease of use
and availability; it is the number one, dominating law for security.

But the enemy of cryptography is time; what was secure then is not now.
It doesn't take much to deal with it, but unfortunately the powers
that be SSL have fiddled around adding more and not chopping away.
Always because someone wants to keep it around.



This is a rock and a hard place. The rock of upgrading has met the hard
place of legacy users.

Where this goes from here is tension: BetterCrypto and groups like it
will continue to deprecate those ciphers. Users will start to suffer.
Users will complain. Mozilla and browsers and so forth will cop the
brunt of the suffering. Very unfair.

But meanwhile the fix is in. And if there is one thing we do know, the
juggernaut of SSL/IETF/PKIX/CABForum/OpenSSL/NSS/NIST/Sun/ and a dozen
other acronyms I've forgotten ... are not going to push on this front.
They are going to do what they always do: act as if every old cipher is
like a limb, squealing and moaning at the thought that it is going to be
cut off, all the while salivating at the chance to add another cipher
suite, more, moar!

:) prove me wrong! See how long it takes to get any of those groups of
power to announce an end of life for RC4. Or 3DES. Bloody android is
still using MD5, last I heard...



BetterCrypto *has to lead* because everyone else is following each other
in a big circle.



iang

[Julien Vehent]

On 2014-01-03 12:58, ianG wrote:
> On 3/01/14 19:24 PM, Julien Vehent wrote:
>> On 2014-01-02 18:59, ianG wrote:
>>> On 3/01/14 01:06 AM, Julien Vehent wrote:
>>>
>>>
>>>> 3DES isn't broken.
>>>
>>>
>>> No, but it is end of life. 112bit security for the 2key variant, and
>>> an 8 byte block makes it just old. If you've got AES there, use it.
>>> Who hasn't got it?
>>
>> See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
>> "Internet Explorer uses the cryptographic library “schannel”, which is
>> OS dependent. schannel supports AES in Windows Vista, but not in Windows
>> XP."
>
>
> Right, Windows XP. Which is end of life.

Microsoft killing support for a product isn't the same thing as people
throwing away their computers.

Or, are you implying that because microsoft is ending the life of XP, we
should feel comfortable disconnecting these people from the internet? I'm not
sure what they did to deserve that, except spending thousands of dollars on a
computer years ago.

>
>
>>> Hmmm.. Are the Chinese blocked from stronger crypto?
>>
>> According to http://www.modern.ie/ie6countdown:
>> * 22.2% of China uses IE6
>> * 4.9% of users worlwide use IE6
>
>
> Thanks for that! More end of life. And DJB says it's worse, we've
> retrograded to about 50% RC4 usage.
>

Apples and Oranges. Some websites owners prefer RC4 for various reasons, but
it's different from what clients can actually negotiate.
Even if all website owners update their ciphersuite tomorrow, that won't
replace the millions of computers than are stuck on RC4 and 3DES.

I'm not sure what, in my message, triggered such a strong reaction. As I
said in a previous email:

"""
1. I think it's great to have two guides with divergent points of view.
I'm mostly
interested in discussing design choices, because these discussions
are useful.
I'm not interested in convincing the ACH group that one
recommendation is better
than the other, since it completely depends on the context.
"""

If anyone has a secret sauce to replace all of the ancient software out
there, with newer one that support TLS1.2, OCSP Stapling and so on, I'm 200%
up for it.
In the meantime, it's important that users can reach mozilla.org from IE6,
so that they can install Firefox and enjoy stronger security.

- Julien

[Falcon Darkstar Momot]

If I may weigh in, one could certainly argue that there isn't any
benefit in allowing these people to believe that their HTTPS connections
are actually secure when they're using ciphers that we know to be broken
(how much we know them to be broken is certainly up for debate).

People can still go to whatever site they want even if they can't use
HTTPS, as long as the site is available over HTTP.

I wouldn't bother actually dropping support for a cipher suite until it
can be trivially broken, though, as that is the point at which it has no
value. Anything else is excessively heavyhanded.

--FalconK

[Julien Vehent]

On 2014-01-03 16:09, Falcon Darkstar Momot wrote:
>
> If I may weigh in, one could certainly argue that there isn't any benefit
> in allowing these people to believe that their HTTPS connections are
> actually secure when they're using ciphers that we know to be broken (how
> much we know them to be broken is certainly up for debate).
>

Even with RC4 or 3DES, that HTTPS icon still tells a user that their abusive
relative can't read their emails on the house's proxy. What we, security
professional, define as secure is widely different from what the average user
wants or needs.

> People can still go to whatever site they want even if they can't use
> HTTPS, as long as the site is available over HTTP.

What if the NSA could break all crypto in the world within seconds? Would we
accept to type our passwords and emails over HTTP then? I suspect not.

> I wouldn't bother actually dropping support for a cipher suite until it
> can be trivially broken, though, as that is the point at which it has no
> value. Anything else is excessively heavyhanded.
>
> --FalconK

- Julien

[ianG]

Hi Julian,

On 4/01/14 00:04 AM, Julien Vehent wrote:
> On 2014-01-03 12:58, ianG wrote:

>> Right, Windows XP. Which is end of life.
>
> Microsoft killing support for a product isn't the same thing as people
> throwing away their computers.
>
> Or, are you implying that because microsoft is ending the life of XP, we
> should feel comfortable disconnecting these people from the internet?
> I'm not sure what they did to deserve that, except spending thousands of
> dollars on a computer years ago.

It depends on your mission. Here, we're seeking better crypto.

At Mozilla, it's clear that you're seeking access to the web for all.
These are very different missions. The mission drives all.

It's pretty clear that users of XP, etc, will not be using better
crypto. They aren't now, they won't as long as they keep using XP.

They are already outside our chosen domain, nothing we can do will bring
them back into it. Only they can act.

>>>> Hmmm.. Are the Chinese blocked from stronger crypto?
>>>
>>> According to http://www.modern.ie/ie6countdown:
>>> * 22.2% of China uses IE6
>>> * 4.9% of users worlwide use IE6
>>
>>
>> Thanks for that! More end of life. And DJB says it's worse, we've
>> retrograded to about 50% RC4 usage.
>>
>
> Apples and Oranges. Some websites owners prefer RC4 for various reasons,
> but it's different from what clients can actually negotiate.
> Even if all website owners update their ciphersuite tomorrow, that won't
> replace the millions of computers than are stuck on RC4 and 3DES.

Right. It's apples and oranges and pears and grapefruits and grapes and
carrots and turnips too. If your mission is to keep these people on the
web, then yes, you need to keep RC4 and 3DES alive.

> I'm not sure what, in my message, triggered such a strong reaction. As I
> said in a previous email:

Oh, my fault, definitely: Mozilla's mission isn't necessarily workable
or adoptable outside Mozilla, so we have to be careful to understand
when and how it causes tensions.

> """
> 1. I think it's great to have two guides with divergent points of
> view. I'm mostly
> interested in discussing design choices, because these
> discussions are useful.
> I'm not interested in convincing the ACH group that one
> recommendation is better
> than the other, since it completely depends on the context.
> """
>
> If anyone has a secret sauce to replace all of the ancient software out
> there, with newer one that support TLS1.2, OCSP Stapling and so on, I'm
> 200% up for it.

There isn't any secret sauce, algorithm agility totally failed as a
solution. Hard decisions have to be made. People will suffer.

Or it gets worse.

To put a date on it, everything changed in 2011. What worked before is
not necessarily going to work any more.

> In the meantime, it's important that users can reach mozilla.org from
> IE6, so that they can install Firefox and enjoy stronger security.

If you mean, stronger security than say HTTP, I'm all for it. My
writings on Mozilla lists to this end are voluminous and drowning...

But it's a long long debate, and once we drag security into it, it gets
messy. Frankly, Mozilla is best off doing what it does: getting web to
users, and following standards. I'm an avid user of Firefox and Tbird,
myself, I don't want these tools to go away.

If there's a message for Mozilla here, it might be this: those old
algorithms may become less useful sooner than we'd like...



iang

[ianG]

On 2/01/14 20:09 PM, Julien Vehent wrote:

> I wish there was references to these "discussions".

The problem with any references to rationale is that it often goes into
arguable and unending discussions.

There's a certain value in being quite curt about the recommendation,
and readers can take it or leave it. Obviously, the recommendations can
be wrong, but they are valuable if they are mostly right and easy to
follow. And every name stakes their rep to it.

The document is already huge... which makes it hard to follow...

> My understanding of
> the state of
> the art of ECC is that P-256 is considered at least as secure as DH and
> RSA.

The general issue is all of the standardised EC curves are under a
cloud, in part because of the DUAL_EC saga, and in part because DJB &
Tanje Lange have heavily criticised the standard curves. Have a look at
their table at http://safecurves.cr.yp.to/ there's definitely a problem
with all prior work.

How much is this overdone? I don't think it is as important as the RC4
issue. We know RC4 can be cracked in some standard daily amounts, 16M
and beyond. We don't know that about ECC nor 3DES.

Coming back to public key choice, it is now an open question: Do we
recommend just RSA for now and wait until the new curves come on line?
Or stick with ECC as it is now available, because fears are overblown?
I don't know the answer to that one, but framing the question is often
half the battle.



iang

[Kurt Roeckx]

On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote:
>
> > 3DES isn't broken.

> Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we
> recomend are at least at 128bit security.

The document doesn't seem to say that it's trying to reach a 128
bit security level over the whole chain. It seems to be happy
with 2048 bit RSA keys. They also provide 112 bit security.

If you really want to go for 128 bit, you need to have the RSA
keys of at least something in the order of 3072 bit. If 2048
is fine, 3DES is fine.


Kurt

[ianG]

On 5/01/14 18:27 PM, Kurt Roeckx wrote:
> On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote:
>>
>>> 3DES isn't broken.
>> Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we
>> recomend are at least at 128bit security.
>
> The document doesn't seem to say that it's trying to reach a 128
> bit security level over the whole chain. It seems to be happy
> with 2048 bit RSA keys. They also provide 112 bit security.

As others have mentioned, these aren't quite comparable. 3DES has an 8
byte block, which gives its own problems. AES is a stronger more modern
algorithm.

Key length isn't an exact proxy for security.

Also, the setting of the RSA key is more driven by software capabilities
and CA's capabilities & compliances with mountains of documents than
anything else. Rather chalk & cheese, you can't just wind up the RSA
key size by setting a param in config, more's the pity.

iang

> If you really want to go for 128 bit, you need to have the RSA
> keys of at least something in the order of 3072 bit. If 2048
> is fine, 3DES is fine.
>
>
> Kurt
>

> _______________________________________________
> Ach mailing list
> A...@lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>

[cl...@jhcloos.com]

Julien Vehent <jul...@linuxwall.info> writes:

> I would argue that our documents target server configurations, where
> AES-NI is now a standard.

It is not. Many sites run on virtuals, often using kvm. And most kvm
sites provide a QEMU Virtual CPU which only supports sse2.

And even without kvm, there is still a /lot/ of pre-aes-ni hardware in use.

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6

[Aaron Zauner]

Hi Kurt,

On 02 Jan 2014, at 21:51, Kurt Roeckx <ku...@roeckx.be> wrote:

> On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:

>>> I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite.
>>> But the construction must be wrong because it returns AES first. If the intent is to
>>> prefer Camellia, then I am most interesting in the rationale.
>> Thanks for reporting this!
>>

>> Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody
>> is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the
>> same security.
>

> I know that for AES people having been putting an effort in making
> this constant time. Having AES-NI clearly helps with this. I
> can't say the same for Camellia and so think it doesn't make sense
> to prefer it over AES.

Yes.

> NSS/Firefox currently still has Camellia as first non-ECDHE and
> as result does use it for sites supporting it. But as far as I
> know it's the only browser supporting it, and the next version is
> going to prefer AES over Camellia all the time which resulted in
> it's usage going from about 5% to as good as 0%.

Sadly, yes. Camellia is a good cipher, but with AES-NI it’s almost irrelevant to TLS traffic.

> There has also been talk about either disbaling it by default
> or even dropping support for it but that currently didn't happen
> yet.

That’s a good point. We might want to review this decision.
We generally do that during meet ups (are reported onto the ML) or on the mailing list.

What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way?

Thanks,
Aaron

[Aaron Zauner]

ARGH! Third time’s a charm: BEAST.

BREACH is CRIME related and has nothing to do with that.

Aaron

[Aaron Zauner]

Hi Julien,

On 02 Jan 2014, at 23:06, Julien Vehent <jul...@linuxwall.info> wrote:

>
> 2. My experience as a web hosting engineer, and sysadmin, has convinced me that
> building security recommendations on what academia thinks alone is very dangerous.
> Security doesn't live in a bubble. It depends on people and systems. It must
> protect an activity, but never ever block it entirely.

I’ve also been working as a systems engineer and developer for more than 6 years now and did a lot of FOSS related stuff before that.
I do not think that is true. Usually there is a finding in academia that people exploit a short afterwards. Yes it’s pratical. Look at CRIME
and padding-oracle attacks in general for an example of TLS insecurity that resulted of research (and recommendations) by academia.

> Others at Mozilla, Google and major organizations have decided
> to implement ECC, and we trust their decision.

The findings by Bernstein et at. are relatively new. I do expect people to react sooner or later. I also expect there to be a lot of new
research and possibly real-life TLS security implications. But I might be wrong.

> Aside from performance, timing attacks are apparently easier in AES-256.
> https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ

Thanks, we’ll make sure to include this to the paper. I have no problem with AES-128, personally that is what I would have chosen,
the overhead of AES256 is just to much for e.g. hosting environments or large traffic websites. I’ve also remarked upon this a couple
of times. But the decision is not mine alone to make.

> 3DES isn't broken.
Triple DES provides about 112bit security (We’ve a section on the topic in the Paper in the Keylenghts section). All ciphers that we
recomend are at least at 128bit security.

See also: http://crypto.stackexchange.com/questions/6345/why-is-triple-des-using-three-different-keys-vulnerable-to-a-meet-in-the-middle

> RC4 is broken, but I am yet to see a practical attack that doesn't require gigabits of traffic.

> Again, this is the tradeoff between what academia thinks is secure, and the level of security
> users need. It's more important for us to allow Chinese users to download Firefox, than it is
> to disable RC4 (that westerners almost never use anyway).

Thats just what one attack suggests, there may be improvements or even better attack vectors.
Recent leaks started discussion in the crypto community about a possible breakthrough by the NSA so that they can exploit RC4 in real
time. This has only been implied by leaked documents and nothing was yet disclosed that proofs this theory. But when I talk about end-user
security I might want to consider that NSA has some of the best cryptanalysts and mathematicians at their disposal. And after all they are a
threat to online security. Microsoft recently labeled the US Govt. as APT. And thats not even the only issue I have with RC4, those findings
regarding TLS have been published in March. There are a lot of attack vectors known for RC4: http://en.wikipedia.org/wiki/RC4#Security
The literature is full of them, I think wikipedia only states a third or so. Even if those are academic publications some may potentially be
adopted and used on TLS traffic. I just don’t feel safe recommending RC4 to anyone, and I havent felt safe about RC4 in the last years
either. After BREAK there was this huge outcry by “security professionals” to switch to RC4, I still think that was a dumb idea.

> For us, it's a choice between DHE with 1024, or no DHE at all. We will not block a subgroup
> of users because they don't support larger keys. And I suspect no business ever will.

Of course. Our paper is only a recommendation and things that we’d like to see implemented.

> RSA key rotations happen very rarely in hosting environments. Except when the CA requires it,
> it's not uncommon to see private keys that are several years old. Keys also move very easily,
> end up in people's mailboxes or shared folders, or get stored in cloud providers that don't
> zero their disks after use.

Yes. But thats a huge issue. People actually should regenerate their keys frequently. As more traffic is encrypted with one key the easier
it gets to mount different attacks on the server (e.g. chosen ciphertext attacks). The issue you mentioned with Keys being mailed is an
obvious one but we do not provide a guide on OPSEC. Of course that should not happen but it does.

Thanks for your time and feedback,
Aaron

[Aaron Zauner]

Hi Julien,

I took the liberty to answer a few of your questions (in CC to dev-tech-crypto and ach). Others might want to add something as well:

On 02 Jan 2014, at 18:09, Julien Vehent <jul...@linuxwall.info> wrote:

> Overall, I think this guide is great! The configuration examples are very useful.
> It's also good to have multiple TLS guides with different audiences, so I'm definitely
> glad to see more people take on the issue.

Thank you.

> Why prefer DHE to ECDHE, when the former is 3 times slower than the later?
> There is a bit of a justification in 3.5:
> "Since there is much discussion on the security of ECC, flawed settings might very
> well compromise the security of the entire system."

> I wish there was references to these "discussions". My understanding of the state of

> the art of ECC is that P-256 is considered at least as secure as DH and RSA.

Well, no. Bernstein and Lange have been auditing NIST/SECG and other standardized curves that are
currently implemented in crypto libraries over the last years. They may be considered secure against
the ECDLP (some) but other issues remain that caused us to prefer DHe over ECDHe.
We’re aware of the performance implications - the paper in general tries to cope with best performance
and backwards compatability, but not at the cost of security. I’m aware that this philosophy might differ
to that of the Mozilla Security Team. Recent publications have prompted some change in mindset though
and one cannot recommend a security guide that takes all factors into consideration at the potential cost
of (side channel) attacks or downgrade attacks.

Please take the time to read up on:
- http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
- http://safecurves.cr.yp.to/
- http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters
(There’s also interesting research to Koblitz curves in the reply by thomas pornin)

>

> They recommend AES-128 in "3.4. Keylengths", but publish a ciphersuite that prefers
> AES-256 (see below). This is probably just an oversight, the guide is still in "Draft”.
Our viewpoint was that if possible, take a stronger cipher. We’re aware that people might want
to change this in their configuration if performance is paramount. We probably should discuss this again.

> The guide is not backward compatible with all clients. We, at Mozilla, must maintain
> backward compatibility with even the oldest, most broken, clients on the internet, and
> this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4,
> and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could
> just remove these two ciphers, but it's not a realistic goal in the near future.
I personally think this is the wrong descision. I’m aware that you want to cater to as many clients as possible,
but you also want to ship a solid and secure product. What people see and care about when they surf from
XP machines using RC4 or 3DES is this nice green padlock in the browser bar. What they actually get as
security are ciphers that have been considered insecure in academia for now over 15 years.

> Same goes for the recommendation to use DH parameters > 1024 bits. We tried using a 2048
> bits parameter a few months back. We first noticed a big spike in CPU usage, caused by
> the largest exponentiation, but that was still acceptable. What forced the rollback is
> the long list of java 6 clients that broke, because they don't accept DH keys > 1024 bits.

> Until all of these clients get fixed, DH params will be limited to 1024 bits.
As far as I know stronger DH params are supported by the Java Crypto Extensions package. That said
it’s usually not deployed anywhere. We’re aware of the issue but using DH parameters of 1024 bits only
can provide security that is slightly less than 1024bit RSA which can certainly be factored by large agencies.
- It takes you about 48hours to factor 512bit RSA keys in EC2: http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
- The largest Key factored by public research (in a small university setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006

We hope that Java will adopt a reasonable security policy in the future, although I’m personally not conviced that they will.

> I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite.
> But the construction must be wrong because it returns AES first. If the intent is to
> prefer Camellia, then I am most interesting in the rationale.
Thanks for reporting this!

Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody
is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the

[Aaron Zauner]

On 03 Jan 2014, at 00:19, Aaron Zauner <az...@azet.org> wrote:

> After BREAK there was this huge outcry by “security professionals” to switch to RC4, I still think that was a dumb idea.

Sorry. BREACH of course.

Aaron

[Adi Kriegisch]

Hi!

Sorry for being rather late in my reply; most of your questions/remarks are
already answered.

> The guide is not backward compatible with all clients. We, at Mozilla, must maintain
> backward compatibility with even the oldest, most broken, clients on the internet, and
> this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4,
> and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could
> just remove these two ciphers, but it's not a realistic goal in the near future.

True. I personally consider unsupported software depreciated and will not
put effort in supporting it.
In case you need to support WinXP and Java6 we discussed a workaround some
months ago: you may simply use the lack of SNI support in those software
stacks to provide a default virtual host with a weaker cipher set hinting
the user to upgrade their clients/cryptostack/os/whatever.
Java7, however, supports SNI -- therefor this will not work for Java7.
Another possibility would be to filter access to certain services (login
for example) based on a cipher white list: only users with strong ciphers
are allowed to access the login page; the rest gets redirected to a
different page. Both of those recommendations are way beyond the scope of
our guide, I guess. And at least the second one is not trivial to get
right... ;-)

There is another aspect too: this cipher string is meant to protect secrets
(passwords and the like) for at least some reasonable amount of time, so I
see no way to offer support for Java6 or WinXP (at least with its default
crypto stack). If I understood correctly you are trying to achieve some
kind of opportunistic encryption where it does not matter that much how
strong the crypto around the download really is: if that is the case, you
may just enable 3DES and/or RC4 and you're fine off. But that case is
different for two reasons: First you are a real sysadmin able to choose on
your own (which is excellent btw.) and second there is a difference in
secrets that need protection.

> I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite.
> But the construction must be wrong because it returns AES first. If the intent is to
> prefer Camellia, then I am most interesting in the rationale.

The intention of the cipher string is to support both: CAMELLIA and AES as
ENISA recommends in their paper too.
That it returns AES first is unfortunate and caused by OpenSSL: all the
CAMELLIA suites in TLSv1.2 aren't implemented in OpenSSL, so e.g. no
CAMELLIA+GCM is available and no CAMELLIA with SHA-2.
The ordering of ciphers by putting SSLv3 (and TLSv1.0) at the end and
prefering TLSv1.2 is obvious (see +SSLv3 in the cipher string).

> ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and
> makes the
> ciphersuite portable to systems that prefer ECDSA certicates (granted,

> it's not that many...).
Yup. We disabled DSA because all our recommendations deal with RSA; adding
DSA would need more research on best practices and the like around DSA.

-- Adi

[Aaron Zauner]

Hi Kurt,

That is true, the issue being that some software and hardware platforms do
not support RSA keys above 2048bit as of now.

I mean - I do not really have an issue with discussing to put 3DES in
there. We were a bit time restricted to do our research (i.e. we limited
ourselves to certain ciphers) and since this is still in draft stage we're
able to change things like that.

Input from anyone else on the list?

Thanks,
Aaron

On Sun, Jan 5, 2014 at 4:27 PM, Kurt Roeckx <ku...@roeckx.be> wrote:

> On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote:
> >

> > > 3DES isn't broken.
> > Triple DES provides about 112bit security (We've a section on the topic
> in the Paper in the Keylenghts section). All ciphers that we
> > recomend are at least at 128bit security.
>

> The document doesn't seem to say that it's trying to reach a 128
> bit security level over the whole chain. It seems to be happy
> with 2048 bit RSA keys. They also provide 112 bit security.
>

[Alexander Wuerstlein]

On 14-01-05 16:56, Aaron Zauner <az...@azet.org> wrote:
> On Sun, Jan 5, 2014 at 4:27 PM, Kurt Roeckx <ku...@roeckx.be> wrote:
>
> > On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote:
> > >
> > > > 3DES isn't broken.
> > > Triple DES provides about 112bit security (We've a section on the topic
> > in the Paper in the Keylenghts section). All ciphers that we
> > > recomend are at least at 128bit security.
> >
> > The document doesn't seem to say that it's trying to reach a 128
> > bit security level over the whole chain. It seems to be happy
> > with 2048 bit RSA keys. They also provide 112 bit security.
> >
> > If you really want to go for 128 bit, you need to have the RSA
> > keys of at least something in the order of 3072 bit. If 2048
> > is fine, 3DES is fine.
>

> That is true, the issue being that some software and hardware platforms do
> not support RSA keys above 2048bit as of now.
>
> I mean - I do not really have an issue with discussing to put 3DES in
> there. We were a bit time restricted to do our research (i.e. we limited
> ourselves to certain ciphers) and since this is still in draft stage we're
> able to change things like that.
>
> Input from anyone else on the list?

While there are certain uses for 3DES, e.g. backward-compatibility in
cases where its really necessary, generally 3DES being EOL should be a
red flag imho: no further research from the good guys will go into 3DES,
since all the papers would be rejected with "oh, that old crap, don't
you have something interesting?". Otoh, this is a great situation for
the bad guys.

Also, since especially coming from the browser crowd efficiency seems to
be a concern 3DES is worse than the alternatives like AES.

Generally I would suggest keeping the current level of security (128
bit, except where maybe RSA doesn't work for some reasons) and maybe
provide a hint like "We don't recommend 3DES, but if you really really
need it for old crap like Win XP or Java, add this:...". And if in the
general case some old clients can't connect, so be it, maybe they'll
take the hint and upgrade, fix their stuff, etc. Vendors will only fix
stuff if enough users start complaining (for non-EOL products) and users
will only update if stuff doesn't work.



Ciao,

Alexander Wuerstlein.

[Rainer Hoerbe]

+1 for 3DES. And also prioritizing AES128 over AES256 in suite B for the same reason. This saves approx. 40% cpu cycles, and 128-bit security still has lots of reserve.

- Rainer
Am 05.01.2014 um 16:55 schrieb Aaron Zauner <az...@azet.org>:

> Hi Kurt,

>
> That is true, the issue being that some software and hardware platforms do not support RSA keys above 2048bit as of now.
>
> I mean - I do not really have an issue with discussing to put 3DES in there. We were a bit time restricted to do our research (i.e. we limited ourselves to certain ciphers) and since this is still in draft stage we're able to change things like that.
>
> Input from anyone else on the list?
>

> Thanks,
> Aaron

>
>
> On Sun, Jan 5, 2014 at 4:27 PM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote:
> >
> > > 3DES isn't broken.
> > Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we
> > recomend are at least at 128bit security.
>
> The document doesn't seem to say that it's trying to reach a 128
> bit security level over the whole chain. It seems to be happy
> with 2048 bit RSA keys. They also provide 112 bit security.
>
> If you really want to go for 128 bit, you need to have the RSA
> keys of at least something in the order of 3072 bit. If 2048
> is fine, 3DES is fine.
>
>

[L. Aaron Kaplan]

On Jan 5, 2014, at 4:27 PM, Kurt Roeckx <ku...@roeckx.be> wrote:

> On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote:
>>
>>> 3DES isn't broken.
>> Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we
>> recomend are at least at 128bit security.
>
> The document doesn't seem to say that it's trying to reach a 128
> bit security level over the whole chain. It seems to be happy
> with 2048 bit RSA keys. They also provide 112 bit security.
>

True, that's inconsistent.
I'll put it to the TODO list.

> If you really want to go for 128 bit, you need to have the RSA
> keys of at least something in the order of 3072 bit. If 2048
> is fine, 3DES is fine.
>
>
> Kurt
>
> _______________________________________________
> Ach mailing list
> A...@lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

---
// L. Aaron Kaplan <kap...@cert.at> - T: +43 1 5056416 78
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg

[Kurt Roeckx]

On 2013-12-15 02:41, Brian Smith wrote:
> On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka <cai....@gmail.com> wrote:
>
>>> 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!.
>>
>
> In Firefox 27 or later, Yahoo! will choose TLS_RSA_WITH_AES_128_CBC_SHA
> instead, because of the cipher suite order change in Firefox 27.

I'm not sure what you mean with "Yahoo!", they have several sites each
with their own settings. Some of them set the preferred order at the
server side and prefer RC4 and so we end up with RC4.

I'm considering if we should also drop support for RC4 on the client
side. At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES.


Kurt

[Julien Vehent]

On 2014-01-09 06:41, Kurt Roeckx wrote:
> I'm considering if we should also drop support for RC4 on the client side.
> At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES.

I started a scan of Alexa's top 1 million websites. It's going to take a few
days to have all the results.
So far, 21 out of 1396 websites scanned support neither AES or 3DES.

All of these sites are high traffic:

lynda.com
priceline.com
adultfriendfinder.com
siteground.com
lacaixa.es
mmotraffic.com
hostmonster.com
elance.com
vine.co
cvs.com
tharunaya.co.uk
directv.com
goal.com
bluehost.com
typepad.com
inbox.com
sprint.com
squarespace.com
justhost.com
123rf.com
hostgator.com

The (partial) results are here: http://4u.1nw.eu/top1m_ciphersuite_scan.tar
I'll do more number crunching once the scan is done.

The numbers show that deprecating RC4 in Firefox would have real impact on
big websites. Whether we think that's a good or bad thing is up for
discussion :)

- Julien

[Kurt Roeckx]

On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote:
> On 2014-01-09 06:41, Kurt Roeckx wrote:
> >I'm considering if we should also drop support for RC4 on the
> >client side. At least IE11 on windows 8.1 doesn't do RC4, but does
> >do 3DES.
>
> I started a scan of Alexa's top 1 million websites. It's going to
> take a few days to have all the results.
> So far, 21 out of 1396 websites scanned support neither AES or 3DES.

For all the ones I looked it, they only have RC4 enabled.

So I have to wonder, do are those sites that people in general use
without ssl? Or does IE11 have some fallback mechanism that it
enables RC4 if it first fails to negiotate a protocol?


Kurt

[Julien Vehent]

> On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote:
>> I started a scan of Alexa's top 1 million websites. It's going to
>> take a few days to have all the results.
>> So far, 21 out of 1396 websites scanned support neither AES or 3DES.

I'm about half way through the scan, but it's unlikely that the numbers will
change from now. The raw results are below, and I posted an analysis on my
blog: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey


SSL/TLS survey of 317270 websites from Alexa's top 1 million

Supported Ciphers Count Percent
-------------------------+---------+-------
3DES 297625 93.8081
3DES Only 3952 1.2456
AES 290409 91.5337
AES Only 298 0.0939
CAMELLIA 120302 37.9179
CAMELLIA Only 1 0.0003
RC4 282139 88.9271
RC4 Only 4838 1.5249
z:ADH-DES-CBC-SHA 651 0.2052
z:ADH-SEED-SHA 418 0.1317
z:AECDH-NULL-SHA 1 0.0003
z:DES-CBC-MD5 38276 12.0642
z:DES-CBC-SHA 88306 27.8331
z:DHE-DSS-SEED-SHA 1 0.0003
z:DHE-RSA-SEED-SHA 55195 17.3969
z:ECDHE-RSA-NULL-SHA 1 0.0003
z:EDH-DSS-DES-CBC-SHA 6 0.0019
z:EDH-RSA-DES-CBC-SHA 82910 26.1323
z:EXP-ADH-DES-CBC-SHA 451 0.1422
z:EXP-DES-CBC-SHA 68527 21.599
z:EXP-EDH-DSS-DES-CBC-SHA 6 0.0019
z:EXP-EDH-RSA-DES-CBC-SHA 60199 18.9741
z:EXP-RC2-CBC-MD5 73301 23.1037
z:IDEA-CBC-MD5 5248 1.6541
z:IDEA-CBC-SHA 37419 11.7941
z:NULL-MD5 291 0.0917
z:NULL-SHA 290 0.0914
z:NULL-SHA256 5 0.0016
z:RC2-CBC-MD5 43848 13.8204
z:SEED-SHA 65974 20.7943

Supported Handshakes Count Percent
-------------------------+---------+-------
DHE 188739 59.4884
ECDHE 67560 21.2942

Supported PFS Count Percent PFS Percent
-------------------------+---------+--------+-----------
DH,1024bits 185200 58.373 98.1249
DH,1539bits 1 0.0003 0.0005
DH,2048bits 2751 0.8671 1.4576
DH,3072bits 2 0.0006 0.0011
DH,3248bits 2 0.0006 0.0011
DH,4096bits 99 0.0312 0.0525
DH,512bits 58 0.0183 0.0307
DH,768bits 628 0.1979 0.3327
ECDH,B-163,163bits 24 0.0076 0.0355
ECDH,B-233,233bits 236 0.0744 0.3493
ECDH,B-571,570bits 249 0.0785 0.3686
ECDH,P-224,224bits 3 0.0009 0.0044
ECDH,P-256,256bits 66920 21.0924 99.0527
ECDH,P-384,384bits 78 0.0246 0.1155
ECDH,P-521,521bits 94 0.0296 0.1391
Prefer PFS 194554 61.3213 0
Support PFS 239997 75.6444 0

Supported Protocols Count Percent
-------------------------+---------+-------
SSL2 59615 18.79
SSL2 Only 28 0.0088
SSL3 316052 99.6161
SSL3 Only 3539 1.1155
TLS1 313399 98.7799
TLS1 Only 557 0.1756
TLS1.1 100425 31.6529
TLS1.2 103612 32.6574
TLS1.2 Only 3 0.0009
TLS1.2 but not 1.1 8338 2.628


---
Julien Vehent
http://jve.linuxwall.info

[Kurt Roeckx]

On Fri, Jan 10, 2014 at 08:11:02PM -0500, Julien Vehent wrote:
> >On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote:
> >>I started a scan of Alexa's top 1 million websites. It's going to
> >>take a few days to have all the results.
> >>So far, 21 out of 1396 websites scanned support neither AES or 3DES.
>
> I'm about half way through the scan, but it's unlikely that the
> numbers will change from now. The raw results are below, and I
> posted an analysis on my blog:
> https://jve.linuxwall.info/blog/index.php?post/TLS_Survey

Thanks for doing this. There are some pretty scary numbers in
there.


Kurt

[hsiv...@hsivonen.fi]

On Friday, January 3, 2014 6:24:23 PM UTC+2, Julien Vehent wrote:
> According to http://www.modern.ie/ie6countdown:
>
> * 22.2% of China uses IE6
>
> * 4.9% of users worlwide use IE6
>
> I believe that our jobs, as security professionals, is to provide the best
> security to everyone. Not only to the people that have a better access to
> technology.

I think it would be good to separate these four questions:

1) What ciphersuite list should Firefox use for initial TLS handshake? (Hopefully no RC4 ciphersuites on this list in the future--following IE11's lead.)

2) What ciphersuite list should Firefox use for a downgrade handshake? (Probably needs to include RC4 ciphersuites for some time.)

3) What ciphersuite list should Mozilla recommend to Mozilla servers that aren't on the Firefox download path and to third-party server admins? (Hopefully this list wouldn't be influenced by IE on XP--at least not after April.)

4) What ciphersuite list should Mozilla use for those servers that IE on XP needs to handshake with in order for the user to use IE on XP to download Firefox?

It seems that the OP focused on #1, you are focusing on #4 and there are others who are focusing on #3.

I think https://wiki.mozilla.org/Security/Server_Side_TLS would become better if it distinguished between #3 and #4, since the doc is read by third-party admins but Mozilla is a special case, because Mozilla needs to make it possible to download Firefox using IE on XP and, therefore, needs to use a worse config than what third parties could use for their servers.

BTW, is there any progress in terms of getting the vendor that needs to connect to Mozilla's servers using Java 6 to upgrade?

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[ripb...@aol.com]

Hi,
So I didn't get to the bottom of this thread because some of it is 'loading' but I didn't see any mention of NIST 800-131a in all the posts I saw.

This standard (along with NIST 800-57 Part 1) provides information about security strength and what is required. Basically NIST is saying you should have at least 112 bit security by 2014 and that this is generally acceptable to 2031. They also say that you have to use FIPS approved algorithms.

The list of approved algorithms and related security strength as related to TLS cipher suites and certificates:

Encryption:
AES-256 - 256 bit
AES-192 - 192 bit
AES-128 - 128 bit
Triple-Key Triple DES (3DES) - 112 bit

(NOTICE: No Camilla, RC4, SEED, DES or 2DES).

Digital Signature Generation:
DSA with p>=2048, q>=224 - 112 bit
RSA with n>=2048 - 112 bit
EC-DSA with n>224 - 112 bit

This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024).

Hash Functions:
Digital Signature Generation:
SHA-224: 112 bit
SHA-256: 128 bit
SHA-384: 192 bit
SHA-512: 256 bit

(NOTICE: No MD5, no SHA-1)

MAC Generation:
HMAC with key >= 112 bits (note: SHA-1 can be used in MAC)
CMAC with 3DES - 112 bit
CMAC with AES - 128 bit+
CCM
GCM/GMAC

Related, NIST says some environments may need more than 112 bit security and offers two profiles, NSA Suite B - 128 bit and NSA Suite B - 192 bit (RFC 6460)

For Suite B TLS, GCM cipher suites MUST be used; therefore, a Suite B TLS
client MUST implement TLS version 1.2 or later.

A Suite B TLS client configured at a minimum level of security of 128
bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the
ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
cipher suite is preferred; if offered, it MUST appear before the
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite.

If configured at a minimum level of security of 192 bits, the client
MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite
and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher
suite.

So starting with:


These are the default available ciphersuits in Firefox Aurora 28.0a2 on a Windows system:
C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
002F TLS_RSA_WITH_AES_128_CBC_SHA
0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA
0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5


I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list,
I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuratoin switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom if the preference list.

I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over
AES_256 or SHA-256 or SHA-384.

3DES is still acceptable for 2014.
The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it.
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when TLS 1.0 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.1 or TLS 1.2 - just leave it at the bottom as you have it. This is less important since I don't think DSA certrificates are much used.
0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

For forward perfect secrecy (a good thing even if it hurts performance some) - perfer EC-DHE and DHE over RSA key negotiation.
For performance, prefer EC_DHE over DHE.
you seem to have done that.

I'm also not sure why you aren't supporting:
C0 08 - TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
00 13 - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
00 16 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
If the answer is no one uses them or not in NSS - that's fine. However they would be OK for NIST 800-131a.

Might also ask why you didn't include any DH key negotiation cipher suites (e.g. C004, C003, 0031, 0030, 000D, 0010)
It's OK for the server to have a static DH key provided the client uses an ephemeral DH key.
If the answer is no one uses them or not in NSS - that's fine. However the above ones would be OK for NIST 800-131a.

Not sure why you included C02B and C02F or why they are at the top. The SHA-256 is overkill for 2014 - I know if you want GCM - it only comes with at least SHA-256. I haven't researched GCM vs CBC. My first take would be you don't need them - but there might be some reason to include and maybe even to put first. C02B does allow you to support NSA Suite-B 128 if it is first in the list. It's probably OK there but see below about other requirements for Hash and Signature Algorithms.

So - my take after making only the changes to remove non-FIPS algorithms - the list should be in preference order:


C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
002F TLS_RSA_WITH_AES_128_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA


Subject of a separate question to be answered - I don't know if you are sending the Hash and Signature Algorithm extension in the client hello, but to get to 112 bit security (required by NIST 800-131a) - you have to at least offer the extension and allow the server to select SHA-256 - SHA-1 signatures in the TLS protocol are no longer allowed after 2014 per NIST 800-131a.

It would be generally cool if you provided a NIST800-131a or 112 bit configuration control - default to off. In this case, the client offer should offer TLS 1.2, drop SHA-1 from the Hash and Signature ALgorithm extension in the client hello, not allow the server to negotiate down to any TLS less than 1.2, and not allow the server to sign with SHA-1. You should also ensure that certificates have 112 bit strength ( see Digital Signatures, Hashes, above).

It would be generally cool if you supported an NSA-Suite-B-128 and NSA_Suite-B-192 control for folks that want it now. Would require you force TLS 1.2, limit the cipher suites, and approrpriate certificate strengths (No RSA, ECDSA-P256 for 128 bit, ECDSA-P384 for 192 bit). For 128 bit - you have to remove SHA-1 from the Hash and Signature Algorithm extension. For 192 bit - you have to remove SHA-1 and SHA-256 from the Hash and Signature Algorithm extension.

Rick

[Kurt Roeckx]

On 2014-01-27 02:43, ripb...@aol.com wrote:
> Hi,
> So I didn't get to the bottom of this thread because some of it is 'loading'

I really recommend that you do read all the messages. All of this has
been discussed in various thread both here and on other lists.

> Encryption:
> AES-256 - 256 bit
> AES-192 - 192 bit
> AES-128 - 128 bit
> Triple-Key Triple DES (3DES) - 112 bit
>
> (NOTICE: No Camilla, RC4, SEED, DES or 2DES).

Other recommendations don't not recommend 3DES, but do recommend Camellia.

The reason to have RC4 and 3DES enabled is that there are servers that
do not support AES and only support either RC4 or 3DES. Actually
running with RC4 disabled makes me run into some of those sites.

> Digital Signature Generation:
> DSA with p>=2048, q>=224 - 112 bit
> RSA with n>=2048 - 112 bit
> EC-DSA with n>224 - 112 bit
>
> This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024).

Following CA/Browser baseline requirements, everything should now be
2048 bit or more, but some CAs aren't ready for this. 1024 bits is
now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used.

> Hash Functions:
> Digital Signature Generation:
> SHA-224: 112 bit
> SHA-256: 128 bit
> SHA-384: 192 bit
> SHA-512: 256 bit
>
> (NOTICE: No MD5, no SHA-1)

Please note that both MD5 and SHA-1 still have a preimage resistance of
>= 112 bit, but their collision resistance isn't that good. That means
in an HMAC they can perfectly be used.

> A Suite B TLS client configured at a minimum level of security of 128
> bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the

We do not have a minimum level of 128. As you say yourself, 112 bit is
enough.

> I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list,
> I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuratoin switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom if the preference list.

3DES, RC4 and MD5 are actually at the bottom of the list.

> I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over
> AES_256 or SHA-256 or SHA-384.

We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and
so needs SHA256.

> 3DES is still acceptable for 2014.

It's still in the list.

> The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it.
> 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

So maybe you could argue that if we do a fall back from TLS 1.2 to 1.1
that it should be included. But RFC 4346 is obsolete, and I don't see
any real problems with dropping it.

> The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when TLS 1.0 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.1 or TLS 1.2 - just leave it at the bottom as you have it. This is less important since I don't think DSA certrificates are much used.
> 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Also obsolete.

> I'm also not sure why you aren't supporting:
> C0 08 - TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
> 00 13 - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> 00 16 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> If the answer is no one uses them or not in NSS - that's fine. However they would be OK for NIST 800-131a.

3DES is slow, support should be removed, no point in adding support for
it anymore, you should move to AES or Camellia.

> Might also ask why you didn't include any DH key negotiation cipher suites (e.g. C004, C003, 0031, 0030, 000D, 0010)
> It's OK for the server to have a static DH key provided the client uses an ephemeral DH key.
> If the answer is no one uses them or not in NSS - that's fine. However the above ones would be OK for NIST 800-131a.

static (EC)DH keys do not offer forward security. They do cause you to
spend more time on the key exchange. So what is the advantage of them?

> Not sure why you included C02B and C02F or why they are at the top. The SHA-256 is overkill for 2014 - I know if you want GCM - it only comes with at least SHA-256. I haven't researched GCM vs CBC. My first take would be you don't need them - but there might be some reason to include and maybe even to put first. C02B does allow you to support NSA Suite-B 128 if it is first in the list. It's probably OK there but see below about other requirements for Hash and Signature Algorithms.

GCM is an authenticated mode and doesn't use an HMAC. As a result the
collision resistance is more important and you need 256 bits in the hash
to have the 128 bit security level.

> Subject of a separate question to be answered - I don't know if you are sending the Hash and Signature Algorithm extension in the client hello, but to get to 112 bit security (required by NIST 800-131a) - you have to at least offer the extension and allow the server to select SHA-256 - SHA-1 signatures in the TLS protocol are no longer allowed after 2014 per NIST 800-131a.

So it's saying you should only use TLS 1.2. Only about 25% of the
servers support that.


Kurt

[ripb...@aol.com]

On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote:
> I really recommend that you do read all the messages. All of this has >
> been discussed in various thread both here and on other lists.
>

> Ok - I will try (but it will be after this post).

>

> Other recommendations don't not recommend 3DES, but do recommend Camellia.
> The reason to have RC4 and 3DES enabled is that there are servers that>
> do not support AES and only support either RC4 or 3DES. Actually >
> running with RC4 disabled makes me run into some of those sites.>
>

So a few things:
1) I understand 3DES doesn't perform well. You could push them further down
in the preference list if you want to 'not recommend' them more. You
could remove them all together if there are no legacy servers that use
it - but I assume there are.

2) NIST is a US government standards board that drives a lot of compliance
regulation. There are companies what will want to be able show that they
are NIST compliant. The standard at this point does NOT allow you to
use Camellia. So there should be some way to configure the browser so that
it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise you're
probably going to be getting the same sort of feedback about "I can't use
Firefox because it cannot be made NIST 800-131a compliant" that you got
about "I can't use Firefox because it does not support TLS 1.2".

3) NIST/FIPS may eventually allow Camellia. Some folks may want to use it.
Some sites may support it and not support AES. There are reasons to
probably allow Camellia and that should probably be the default for
Firefox general users. However, I would put Camellia lower in the
preference list than AES suites (IMHO).

4) I think the flaws in the TLS 1.1 CBC definition (no random IV) drove
folks away from
AES and to use RC4 - it was the best thing left in TLS 1.1 - or Camellia
which is probably as good or better than AES though rather new and
therefore risky - but better than a broken AES-CBC implementation.

5) I'm trying to tell you what the standard says - not whether I agree with
it. I don't get to pick. The standard does not allow Camellia (because
it is too new). But the standard does support and justify taking away
the set of suites that Marlen suggested. I was just giving a more
explicit rational for dropping them.

>
> > Digital Signature Generation:

> > RSA with n>=2048 - 112 bit
>

> > This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024).
>
>
> Following CA/Browser baseline requirements, everything should now be
> 2048 bit or more, but some CAs aren't ready for this. 1024 bits is
> now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used.

The standard is telling you what you should use, not whether anyone does or
not support it. The standard is saying everyone should already be at 112
security bit strength now.
Agree you might as well ignore DSA if no one implemented it which means
you can forget about TLS_DH, TLS_DHE_DSS suites.
I understand some sites may not use RSA-2048 keys in certificates. However
using RSA-1024 bit keys has only 80 bits of security strength which is no
longer secure (NIST worries about it saying secure for say another 20
years). Even worse than RSA-1024 I suspect will be the use of SHA-1 in
certificate signatures.

The client is not obligated to enforce NIST 800-131a. But I
would suggest two things:
1) There should be a visible indication whenever a web site ends up with a
connections that has less than 112 bit security. Perhaps even ask the
user if he really wants to connect to a site with 'weak' security. This
might motivate some of these sites to fix their security.
2) There should be a configuration control to block connection to a weak
sites period.
Weak = See description at end of post.
>
>
>
> > Hash Functions:

>
> > (NOTICE: No MD5, no SHA-1)
>
>
>
> Please note that both MD5 and SHA-1 still have a preimage resistance of>
> >= 112 bit, but their collision resistance isn't that good. That means>
> in an HMAC they can perfectly be used.
>

MD5 is not a FIPS approved algorithm. It has known issues with collision
resistance. The NIST 800-131a standard says do not use it - not even in an HMAC. Kind of agree that it should be relatively OK in an HMAC, but any known flaw is a potential attack vector.
SHA-1 is 160 bits which as a hash gives it 80 bit security strength. In an
HMAC, it has 160 bit security which is fine. The item above is about
digital signatures - not MACs - the point is - all those RSA-xxxx/SHA-1
signatures on Certificates out there are NOT good. Also using SHA-1 in the
TLS signing protocol is not good - and that's what you get even with TLS 1.2
if you don't send a Hash and Signature Algorithm extension that prohibits SHA-1.

> A Suite B TLS client configured at a minimum level of security of 128
>

> We do not have a minimum level of 128. As you say yourself, 112 bit is >
> enough.
>

The standards say 112 bit is sufficient for most uses. Some uses may require
128 or 192 bit (now). So most users will want to stay away from suites with big keys and hashes if they can. A configuration switch would be nice to pick between 112 and higher levels and it would not be all that much work to change the set of cipher suites and the Hash and Signature algorithm. Firefox doesn't have to provide this - but it would be handy in some environments. Prehaps even give you something to brag about relative to your competition.

>
> > I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list,
>

> > I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuration switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom if the preference list.

>
>
>
> 3DES, RC4 and MD5 are actually at the bottom of the list.

Putting them at the bottom is going to result in these being used on some sites.
You may need this for legacy perhaps, but it violates NIST 800-131a compliance.
Folks that need compliance are going to want them out of the list.

>
>
>
> > I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over
>
> > AES_256 or SHA-256 or SHA-384.
>
> We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and >
> so needs SHA256.
>

There's not much point in having one algorithm with more security than another - the least secure algorithm determines the security level of the implementation and the higher security algorithm just burns performance. AES-128 and SHA-256 hashes are same strength. AES-192 and SHA-384 hashes are same strength. AES-256 and SHA-512 hashes are the same strength.
For 112 bit security strength - AES-128 is sufficient so don't need AES-256. HMAC with SHA-1 is good with AES-128. GMC with SHA-256 is good with AES-128.

> > 3DES is still acceptable for 2014.
>
> It's still in the list.

>
> > The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346).

> > 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA
>
> So maybe you could argue that if we do a fall back from TLS 1.2 to 1.1>
> that it should be included. But RFC 4346 is obsolete, and I don't see >
> any real problems with dropping it.
>

Well again it comes back to legacy use. Yes 4346 is obsolete, but the fact that
you are failing back to TLS 1.1 says that you are still using 4346 for legacy reasons. If folks followed 4346 when they implemented their TLS 1.1 server, you could count on all TLS 1.1 servers supporting that cipher suite. If not one is using it and the performance is bad - yes maybe you can just drop it. Technically - a TLS 1.2 client should be able to offer TLS 1.2 to a TLS 1.1 server and have the server respond with a serverhello that selects a cipher suite and TLS 1.1. Whether the TLS 1.1 implementations are robust enough to handle this I can't say. However, in this case, you need to give it a cipher suite that it knows or it cannot do this. Supporting the mandatory TLS 1.1 cipher suite seems reasonable in this context. I don't think this is a fail back the way firefox uses the term - this is just the server negotiating what it knows. Actually, 3DES is not obsolete - it's still in TLS 1.2 cipher suites (see Appendix C in 5246) - but it will become obsolete in 2030. I can understand you're bias against it - it's not as strong as AES and it performs worse so there's no reason to support it unless you have sites that require you to in order to connect.

>
> > The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246).

> > 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
>
> Also obsolete.
Same discussion as above in the TLS 1.0 context. However less interesting since almost no DSA implementations.

>
>
>
> > I'm also not sure why you aren't supporting:
>
> > C0 08 - TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA>
> > 00 13 - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA>
> > 00 16 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>
> > If the answer is no one uses them or not in NSS - that's fine. However they would be OK for NIST 800-131a.
>
> 3DES is slow, support should be removed, no point in adding support for
> it anymore, you should move to AES or Camellia.

Since EC is relatively new, it is likely any implementation that supports EC would support AES (or you might say Camellia). And DSA has little or no support so probably also OK to drop. I'd possibly question the DHE_RSA if there are any legacy servers out there that would support this as their only forward perfect secret suite. Don't have any data to indicate that but someone else might.

>
> > Might also ask why you didn't include any DH key negotiation cipher suites (e.g. C004, C003, 0031, 0030, 000D, 0010)>
> > It's OK for the server to have a static DH key provided the client uses an ephemeral DH key.>
> > If the answer is no one uses them or not in NSS - that's fine. However the above ones would be OK for NIST 800-131a.
>
> static (EC)DH keys do not offer forward security. They do cause you to
> spend more time on the key exchange. So what is the advantage of them?

I might be wrong, but I thought as long as the client and the server do not BOTH use a static key, then you still have forward perfect secrecy. And I thought the definition in TLS provided for the certificate owner to have a static DH key and for the authenticator to use an ephemeral key when DH or ECDH was used. If this is correct, I'd guess the static key on the server side might save some time. Anyway I'm on shaky ground here perhaps - in my mind, I like it when there are fewer options and clearer choices about what to use. I do notice that the Suite B cipher suites only use ECDHE so that might be some indication that DH or ECDH are not a strategic path. Again - the only point is the standard allows them if there is any reason to support them.

>
>
>
> > Not sure why you included C02B and C02F or why they are at the top. The SHA-256 is overkill for 2014 - I know if you want GCM - it only comes with at least SHA-256. I haven't researched GCM vs CBC. My first take would be you don't need them - but there might be some reason to include and maybe even to put first. C02B does allow you to support NSA Suite-B 128 if it is first in the list. It's probably OK there but see below about other requirements for Hash and Signature Algorithms.
>
> GCM is an authenticated mode and doesn't use an HMAC. As a result the
> collision resistance is more important and you need 256 bits in the hash
> to have the 128 bit security level.
>
>
>
> > Subject of a separate question to be answered - I don't know if you are sending the Hash and Signature Algorithm extension in the client hello, but to get to 112 bit security (required by NIST 800-131a) - you have to at least offer the extension and allow the server to select SHA-256 - SHA-1 signatures in the TLS protocol are no longer allowed after 2014 per NIST 800-131a.
>
> So it's saying you should only use TLS 1.2. Only about 25% of the>
> servers support that.
>

The logic goes like this:
1) SHA-1 does not have 112 bit security strength (so not good after 2014)
2) The TLS protocol has the certificate owner sign something to prove it
owns the private key.
3) The authentication certificate determines the public and private key
used to sign with, but it does NOT determine the HASH used in the
protocol for
signing. The default definition for TLS (even with TLS 1.2 with no Hash
and Signature ALgorithm extension) is that the server uses SHA-1.
4) To get rid of the SHA-1 signature - you need to negotiate the hash
algorithm to be at least SHA-256.
5) So you need TLS 1.2 because that is the only level of the protocol that
provides a way to control the hash used for signing during the protocol.

So you can't get to 112 bit security strength without:
1) Negotiating TLS 1.2 for connection
2) Using an authentication certificate that has 112 bit security strength
in its trust chain (e.g. RSA-2048 with SHA-256 signature).
3) Negotiating a cipher suite with 112 bit security.
4) Negotiation a hash and signature algorithm with 112 bit security (e.g.
SHA-256)
5) You need a FIPS approved PRNG algorithm and an entropy source with at
least 112 bits of entropy.

If any of these is missing - you are not there yet.

I understand there are a lot of sites that don't meet the above criteria. I believe it should at least be the browsers job to allow a site that does meet these criteria to achieve 112 bit security strength. For sites that do not meet the criteria - it should be more obvious to the user that the do not and that should facilitate the complaining necessary to drive sites to update. And for users with compliance requirements, there should be a switch to say do not connect unless you can get 112 bit security (and FIPS approved algorithms).

And BTW - I haven't heard the answer about the Client hello extension for Hash and Signature Algorithm. Does FF send this? Do we know what % of sites tolerate it?

Rick

[Brian Smith]

On Mon, Jan 27, 2014 at 9:26 AM, <ripb...@aol.com> wrote:
> On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote:
> 2) NIST is a US government standards board that drives a lot of compliance
> regulation. There are companies what will want to be able show that they
> are NIST compliant. The standard at this point does NOT allow you to
> use Camellia. So there should be some way to configure the browser so that
> it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise you're
> probably going to be getting the same sort of feedback about "I can't use
> Firefox because it cannot be made NIST 800-131a compliant" that you got
> about "I can't use Firefox because it does not support TLS 1.2".

Camellia may get disabled by default soon. But, RC4 won't get disabled
by default soon; we may do what MSIE11 does, but that's not quite the
same thing. You can configure Firefox to disable RC4 and Camellia
cipher suites using about:config. Search for "rc4" and "camellia" to
find those prefs.

> 5) I'm trying to tell you what the standard says - not whether I agree with
> it. I don't get to pick. The standard does not allow Camellia (because
> it is too new). But the standard does support and justify taking away
> the set of suites that Marlen suggested. I was just giving a more
> explicit rational for dropping them.

No NIST standard is "the standard" for Firefox.

I have sent feedback to NIST about its draft recommendations for TLS,
trying to convince them that they should change their guidance to be
in line with what web browsers do in their default configurations.
However, NIST doesn't dictate what we do. In particular, we won't
constrain ourselves to doing only things that NIST 800-131a recommends
in the default configuration. However, assuming it isn't too much
work, we'll support options that allow you to configure Firefox to
conform with NIST guidance.

> The client is not obligated to enforce NIST 800-131a. But I
> would suggest two things:
> 1) There should be a visible indication whenever a web site ends up with a
> connections that has less than 112 bit security. Perhaps even ask the
> user if he really wants to connect to a site with 'weak' security. This
> might motivate some of these sites to fix their security.
> 2) There should be a configuration control to block connection to a weak
> sites period.
> Weak = See description at end of post.

This seems like a reasonable suggestion.

>> >= 112 bit, but their collision resistance isn't that good. That means>
>> in an HMAC they can perfectly be used.
>>
> MD5 is not a FIPS approved algorithm. It has known issues with collision
> resistance. The NIST 800-131a standard says do not use it - not even in an HMAC. Kind of agree that it should be relatively OK in an HMAC, but any known flaw is a potential attack vector.

There are real compatibility issues with turning off the
HMAC-MD5-based cipher suite. However, you can turn it off in
about:config; search for "md5"

> SHA-1 is 160 bits which as a hash gives it 80 bit security strength. In an
> HMAC, it has 160 bit security which is fine. The item above is about
> digital signatures - not MACs - the point is - all those RSA-xxxx/SHA-1
> signatures on Certificates out there are NOT good. Also using SHA-1 in the
> TLS signing protocol is not good - and that's what you get even with TLS 1.2
> if you don't send a Hash and Signature Algorithm extension that prohibits SHA-1.

It is a good point that we need to change what we do in the TLS
handshake when we stop accepting SHA-1 signatures.

It may be reasonable to implement a "don't accept SHA-1 signatures"
preference similar to the one we just removed for MD5.

> I might be wrong, but I thought as long as the client and the server do not BOTH use a static key, then you still have forward perfect secrecy. And I thought the definition in TLS provided for the certificate owner to have a static DH key and for the authenticator to use an ephemeral key when DH or ECDH was used. If this is correct, I'd guess the static key on the server side might save some time. Anyway I'm on shaky ground here perhaps - in my mind, I like it when there are fewer options and clearer choices about what to use. I do notice that the Suite B cipher suites only use ECDHE so that might be some indication that DH or ECDH are not a strategic path. Again - the only point is the standard allows them if there is any reason to support them.

I do think that ephemeral-static key exchange is something that we
could consider. I even mentioned it in my original proposal:
https://briansmith.org/browser-ciphersuites-01.html. However, there
are basically zero servers that support it.

> And BTW - I haven't heard the answer about the Client hello extension for Hash and Signature Algorithm. Does FF send this? Do we know what % of sites tolerate it?

We include it in TLS 1.2 client hellos and we include SHA-2 and SHA-1
algorithms in the list.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Kurt Roeckx]

On Mon, Jan 27, 2014 at 09:26:20AM -0800, ripb...@aol.com wrote:
>
> 2) NIST is a US government standards board that drives a lot of compliance
> regulation. There are companies what will want to be able show that they
> are NIST compliant.

I'm sure it is important to some. But I think it would be more
important to get the server to be compliant rather than the
client. The client currently has to work in a lot of different
environments where it can't be sure that the other end is
compliant with those standards.

NIST is, like you said, a US government standard, and as such
doesn't have any official status outside the US. That doesn't
mean that if it has good recommendations that we shouldn't try
to follow them.

But we have to live in the real world, and it's more complicated.

> 4) I think the flaws in the TLS 1.1 CBC definition (no random IV) drove
> folks away from
> AES and to use RC4 - it was the best thing left in TLS 1.1 - or Camellia
> which is probably as good or better than AES though rather new and
> therefore risky - but better than a broken AES-CBC implementation.

I think you mean TLS 1.0?

> 5) I'm trying to tell you what the standard says - not whether I agree with
> it. I don't get to pick. The standard does not allow Camellia (because
> it is too new). But the standard does support and justify taking away
> the set of suites that Marlen suggested. I was just giving a more
> explicit rational for dropping them.

AES is from 1998, Camellia from 2000. I wouldn't call that too
new. But it is used less.

> > > Digital Signature Generation:
> > > RSA with n>=2048 - 112 bit
> >
> > > This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024).
> >
> >
> > Following CA/Browser baseline requirements, everything should now be
> > 2048 bit or more, but some CAs aren't ready for this. 1024 bits is
> > now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used.
>
> The standard is telling you what you should use, not whether anyone does or
> not support it. The standard is saying everyone should already be at 112
> security bit strength now.
> Agree you might as well ignore DSA if no one implemented it which means
> you can forget about TLS_DH, TLS_DHE_DSS suites.
> I understand some sites may not use RSA-2048 keys in certificates. However
> using RSA-1024 bit keys has only 80 bits of security strength which is no
> longer secure (NIST worries about it saying secure for say another 20
> years). Even worse than RSA-1024 I suspect will be the use of SHA-1 in
> certificate signatures.

The CA/Browser requirements are good in changing the certificates
being generated. It resulted in the 1024 bits keys going from 10%
last year to 1% now, and with the current rate should be near 0%
in a few months.

I would also like to see them to change the SHA-1 requirement to
SHA-2, and some CAs are working on that. But there seems to be
existing software that still can't handle it. SHA-1 is known to
be only providing about 60 bit of security for a collision attack,
which is a problem. To make it more hard the CAB requirements
state that the CA should add at least 20 bit of entropy and at
least some people say that that is not enough.

> The client is not obligated to enforce NIST 800-131a. But I
> would suggest two things:
> 1) There should be a visible indication whenever a web site ends up with a
> connections that has less than 112 bit security. Perhaps even ask the
> user if he really wants to connect to a site with 'weak' security. This
> might motivate some of these sites to fix their security.
> 2) There should be a configuration control to block connection to a weak
> sites period.
> Weak = See description at end of post.

You can actually disable things like MD5, RC4 and 3DES and set the
minimum version to TLS 1.2. You will just run into many sites
that just don't work.

It will show you that it's weak or strong if you first click the
icon and press more info. Not sure on what that is based.

> > > I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over
> >
> > > AES_256 or SHA-256 or SHA-384.
> >
> > We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and >
> > so needs SHA256.
> >
> There's not much point in having one algorithm with more security than another - the least secure algorithm determines the security level of the implementation and the higher security algorithm just burns performance. AES-128 and SHA-256 hashes are same strength. AES-192 and SHA-384 hashes are same strength. AES-256 and SHA-512 hashes are the same strength.
> For 112 bit security strength - AES-128 is sufficient so don't need AES-256. HMAC with SHA-1 is good with AES-128. GMC with SHA-256 is good with AES-128.

The SHA-256 in combination with GCM only provides 128 bit, not 256
bit.

> > > Might also ask why you didn't include any DH key negotiation cipher suites (e.g. C004, C003, 0031, 0030, 000D, 0010)>
> > > It's OK for the server to have a static DH key provided the client uses an ephemeral DH key.>
> > > If the answer is no one uses them or not in NSS - that's fine. However the above ones would be OK for NIST 800-131a.
> >
> > static (EC)DH keys do not offer forward security. They do cause you to
> > spend more time on the key exchange. So what is the advantage of them?
>
> I might be wrong, but I thought as long as the client and the server do not BOTH use a static key, then you still have forward perfect secrecy. And I thought the definition in TLS provided for the certificate owner to have a static DH key and for the authenticator to use an ephemeral key when DH or ECDH was used. If this is correct, I'd guess the static key on the server side might save some time. Anyway I'm on shaky ground here perhaps - in my mind, I like it when there are fewer options and clearer choices about what to use. I do notice that the Suite B cipher suites only use ECDHE so that might be some indication that DH or ECDH are not a strategic path. Again - the only point is the standard allows them if there is any reason to support them.

The client DH key is not encrypted. If a client sends the same
DH key to the same server it will end up with the same session
key. Anybody that monitored the communication and later has
access to the servers key will be able decipher everything, and so
it does not provide forward secrecy.



Kurt

[ripb...@aol.com]

On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote:
> On Mon, Jan 27, 2014 at 9:26 AM, <ripb...@aol.com> wrote:
>
> > On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote:
>
> > 2) NIST is a US government standards board that drives a lot of compliance
>
> > regulation. There are companies what will want to be able show that they
>
> > are NIST compliant. The standard at this point does NOT allow you to
>
> > use Camellia. So there should be some way to configure the browser so that
>
> > it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise you're
>
> > probably going to be getting the same sort of feedback about "I can't use
>
> > Firefox because it cannot be made NIST 800-131a compliant" that you got
>
> > about "I can't use Firefox because it does not support TLS 1.2".
>
>
>
> Camellia may get disabled by default soon. But, RC4 won't get disabled
>
> by default soon; we may do what MSIE11 does, but that's not quite the
>
> same thing. You can configure Firefox to disable RC4 and Camellia
>
> cipher suites using about:config. Search for "rc4" and "camellia" to
>
> find those prefs.
>

Camellia disabled by default - I'd say this is appropriate.
Ability to disable RC4 and Camellia - I'd say this was sufficient.

I believe that folks are using RC4 to get around the broken AES-CBC implementation in TLS 1.1. That should revert back to using AES-CBC once they are on TLS 1.2 (in an ideal world) - but in the short term - I agree - you are stuck with defaulting to enabling, hopefully at the bottom of the preference order.

>
>
> > 5) I'm trying to tell you what the standard says - not whether I agree with
>
> > it. I don't get to pick. The standard does not allow Camellia (because
>
> > it is too new). But the standard does support and justify taking away
>
> > the set of suites that Marlen suggested. I was just giving a more
>
> > explicit rational for dropping them.
>
>
>
> No NIST standard is "the standard" for Firefox.

I can't speak for FF - and I've certainly read enough standards to say that there are too many standards. I do think that the IETF does listen to NIST however. And if you care about security, the security of your implementation is a function of the cryptographic algorithms used. So I'd suggest that NIST is telling FF and everyone else where they should be to be secure. That being said, the reality of rolling forward to a new security level in the real world is much more of a random walk through the park. I appreciate your consideration of my comments.

>
>
>
> I have sent feedback to NIST about its draft recommendations for TLS,
>
> trying to convince them that they should change their guidance to be
>
> in line with what web browsers do in their default configurations.
>
> However, NIST doesn't dictate what we do. In particular, we won't
>
> constrain ourselves to doing only things that NIST 800-131a recommends
>
> in the default configuration. However, assuming it isn't too much
>
> work, we'll support options that allow you to configure Firefox to
>
> conform with NIST guidance.
>

That is as good as I could have hoped for Brian.
I'll tell you that (for work reasons) I've had to try to decipher between all the standards what is needed for security compliance. It is much more messy than I had hoped. I have to fault the standards groups for not making it more obvious. If you understand what it is saying, NIST 800-131a is actually pretty clear on what it recommends and why; and it points to other standards that do some of the explaining. However, it would have been very helpful if they had actually bothered in an appendix to indicate all the cipher suites that are OK (for TLS and IPSEC). This might have motivated other standards groups to update other standards and perhaps help more implementors make good choices. I can't even assure you that everything I'm saying is correct - but I think I've got enough background to provide an educated opinion on some of this stuff.

I will say this though. NIST's guide line is about achieving a specific security level that they feel is needed at a given period of time. This has nothing to do with what is out in the real world - it has to do with getting the real world to go where it needs to go. I would like to hear more about what you are recommending NIST do to align with default configurations (perhaps something for a separate email). I work on some server implementations and have an equivalent problem of trying to figure out if I limit the server to be NIST compliant - will it work with any existing browsers? If everyone could get on the same page about what we need to do now and what we need to do soon, we probably wouldn't be having this discussion.

It would be good if the IETF wrote some standards to obsolete stuff that is not used and tell folks to get off stuff that is known to be not secure. Perhaps it is a work in progress - it's hard to keep up. Even better if they had more implementation guidelines for implementors.

>
>
> > The client is not obligated to enforce NIST 800-131a. But I
>
> > would suggest two things:
>
> > 1) There should be a visible indication whenever a web site ends up with a
>
> > connections that has less than 112 bit security. Perhaps even ask the
>
> > user if he really wants to connect to a site with 'weak' security. This
>
> > might motivate some of these sites to fix their security.
>
> > 2) There should be a configuration control to block connection to a weak
>
> > sites period.
>
> > Weak = See description at end of post.
>
>
>
> This seems like a reasonable suggestion.

Again - more than I could have reasonable expected you to agree with.
Thanks.

>
>
>
> >> >= 112 bit, but their collision resistance isn't that good. That means>
>
> >> in an HMAC they can perfectly be used.
>
> >>
>
> > MD5 is not a FIPS approved algorithm. It has known issues with collision
>
> > resistance. The NIST 800-131a standard says do not use it - not even in an HMAC. Kind of agree that it should be relatively OK in an HMAC, but any known flaw is a potential attack vector.
>
>
>
> There are real compatibility issues with turning off the
>
> HMAC-MD5-based cipher suite. However, you can turn it off in
>
> about:config; search for "md5"

Ability to disable MD5 - I think this is sufficient.
Also - sorry about my ignorance about FF configuration controls.

>
>
>
> > SHA-1 is 160 bits which as a hash gives it 80 bit security strength. In an
>
> > HMAC, it has 160 bit security which is fine. The item above is about
>
> > digital signatures - not MACs - the point is - all those RSA-xxxx/SHA-1
>
> > signatures on Certificates out there are NOT good. Also using SHA-1 in the
>
> > TLS signing protocol is not good - and that's what you get even with TLS 1.2
>
> > if you don't send a Hash and Signature Algorithm extension that prohibits SHA-1.
>
>
>
> It is a good point that we need to change what we do in the TLS
>
> handshake when we stop accepting SHA-1 signatures.
>

So first, I'm not asking you to stop accepting SHA-1 signatures (at least not by default). I'm trying to say that if you don't at least offer the server the Hash and Signature Algorithm extension with both SHA-1 and SHA-256, then by 5246 (TLS 1.2) the server is obligated to use SHA-1 for signing. In otherwords, unless the client sends this extension - the server cannot create a NIST 800-131a compliant connection with this client. I see you answered later that you do send this on a TLS 1.2 client. That is sufficient.

>
>
>
> It may be reasonable to implement a "don't accept SHA-1 signatures"
>
> preference similar to the one we just removed for MD5.

A control to stop accepting SHA-1 signatures would be desirable. I would say for the forseeable future, it would have to default to off - I'll give you odds that >90% of the certificates still have SHA-1.

>
>
>
> > I might be wrong, but I thought as long as the client and the server do not BOTH use a static key, then you still have forward perfect secrecy. And I thought the definition in TLS provided for the certificate owner to have a static DH key and for the authenticator to use an ephemeral key when DH or ECDH was used. If this is correct, I'd guess the static key on the server side might save some time. Anyway I'm on shaky ground here perhaps - in my mind, I like it when there are fewer options and clearer choices about what to use. I do notice that the Suite B cipher suites only use ECDHE so that might be some indication that DH or ECDH are not a strategic path. Again - the only point is the standard allows them if there is any reason to support them.
>
>
>
> I do think that ephemeral-static key exchange is something that we
>
> could consider. I even mentioned it in my original proposal:
>
> https://briansmith.org/browser-ciphersuites-01.html. However, there
>
> are basically zero servers that support it.

Standards describe lots of things that are not implemented in the real world. I would be the last one in the world to ask you to support something that no one is using unless it was the only way to achieve some goal that is needed. For example - no one supported TLS 1.2 orignally - but TLS 1.1 was broken so we need to move on. In think ECDHE is going to be strategic (someday). From what I'm hearing, I don't see any need for DH and ECDH in the general world unless something else is said. I would suggest ignore them until someone knocks on your door with a reason about why he has to have it.

>
>


>
> > And BTW - I haven't heard the answer about the Client hello extension for Hash and Signature Algorithm. Does FF send this? Do we know what % of sites tolerate it?
>
>
>
> We include it in TLS 1.2 client hellos and we include SHA-2 and SHA-1
>
> algorithms in the list.

Super - that is what is needed.

So perhaps I'll try to make an offer here. I really like FF's ideology. I'd like to try to put together a set of 'guidelines' for configuring it to be NIST 800-131a compliant - e.g. describe what configuration controls are necessary. I think you've told me most of that above - though I think there were a few other things in the list to check out. I'll take that offline from this chat. It's something I could use in my environment. It might be something that would be useful to others as a reference.

Thanks,
Rick

[Alan Braggins]

On 27/01/14 17:26, ripb...@aol.com wrote:
> 2) NIST is a US government standards board that drives a lot of compliance
> regulation. There are companies what will want to be able show that they
> are NIST compliant. The standard at this point does NOT allow you to
> use Camellia. So there should be some way to configure the browser so that
> it uses only FIPS approved algorithms (i.e. NOT CAMELLIA).

https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation

[Brian Smith]

On Mon, Jan 27, 2014 at 10:49 AM, <ripb...@aol.com> wrote:
> On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote:
>> On Mon, Jan 27, 2014 at 9:26 AM, <ripb...@aol.com> wrote:
>
> I can't speak for FF - and I've certainly read enough standards to say
> that there are too many standards. I do think that the IETF does listen
> to NIST however. And if you care about security, the security of your
> implementation is a function of the cryptographic algorithms used.
> So I'd suggest that NIST is telling FF and everyone else where they
> should be to be secure. That being said, the reality of rolling forward
> to a new security level in the real world is much more of a random
> walk through the park. I appreciate your consideration of my comments.

NIST is one input into the IETF process, and NIST and IETF are both
inputs into our decision making. We also help IETF and NIST to update
their proposed standards. There is currently work going on at the IETF
to define best practices for TLS, including recommended cipher suites,
recommended TLS versions to support, and recommended features to
support. However, I suspect that those recommendations will written
such that they define the minimum set of functionality that a good
implementation should support. I suspect they won't fully define what
an application like Firefox has to do to be simultaneously secure and
backward-compatible. The good news, though, is that things are getting
better all around, AFAICT.

> If you understand what it is saying, NIST 800-131a is
> actually pretty clear on what it recommends and why;
> and it points to other standards that do some of the
> explaining. However, it would have been very helpful
> if they had actually bothered in an appendix to
> indicate all the cipher suites that are OK (for TLS
> and IPSEC).

You should look at the SP800-52 draft, which more clearly specifies
how NIST recommends that TLS applications work.
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-52-Rev.%201.

> I would like to hear more about what you are recommending
> NIST do to align with default configurations (perhaps
> something for a separate email).

I will send my feedback regarding the NIST SP800-52 draft to this
mailing list in a separate thread.

> It would be good if the IETF wrote some standards
> to obsolete stuff that is not used and tell folks to get
> off stuff that is known to be not secure. Perhaps it is
> a work in progress - it's hard to keep up. Even better
> if they had more implementation guidelines for
> implementors.

IETF is currently working on BCP documents to define best practices
for the use of TLS in applications, including web browsers and web
servers. I recommend that you subscribe to the IETF UTA and TLS
working group mailing lists:

https://tools.ietf.org/wg/uta/
https://www.ietf.org/mailman/listinfo/uta
https://tools.ietf.org/wg/tls/
https://www.ietf.org/mailman/listinfo/tls

Also, the HTTP working group at IETF has added some improved minimum
requirements for the use of TLS by HTTP/2 clients and servers, based
on feedback from Mozilla, Google, and others. See
http://http2.github.io/http2-spec/index.html#TLSUsage

> A control to stop accepting SHA-1 signatures would be
> desirable. I would say for the forseeable future, it would
> have to default to off - I'll give you odds that >90% of
> the certificates still have SHA-1.

Agreed. You may be interested in
https://bugzilla.mozilla.org/show_bug.cgi?id=942515 which is about a
way for transitioning away from SHA-1 without breaking backward
compatibility.

> So perhaps I'll try to make an offer here. I really like FF's ideology. I'd like to try to put together a set of 'guidelines' for configuring it to be NIST 800-131a compliant - e.g. describe what configuration controls are necessary. I think you've told me most of that above - though I think there were a few other things in the list to check out. I'll take that offline from this chat. It's something I could use in my environment. It might be something that would be useful to others as a reference.

It would be great if you could write this up. Please start a new
thread with your initial submission. I think one issue you may run
into is that Firefox's current version of NSS isn't FIPS-140
validated. You may find the following useful:
http://kb.mozillazine.org/Security.tls.version.*
https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation

Note that the "FIPS Mode - an explanation" and the support.mozilla.org
article it links to are somewhat outdated.

Also, I recommend that you write your document for Firefox 27 and
later, because Firefox 27 makes substantial changes to the default TLS
configuration of Firefox, including enabling TLS 1.2 and AES-GCM by
default.

Thanks!

[ripb...@aol.com]

On Monday, January 27, 2014 4:35:34 PM UTC-7, Brian Smith wrote:
> On Mon, Jan 27, 2014 at 10:49 AM, <ripb...@aol.com> wrote:
>
> > On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote:
>
> >> On Mon, Jan 27, 2014 at 9:26 AM, <ripb...@aol.com> wrote:

Thanks much Brian and Alan for the links - and the 800-52 reference which I haven't read yet.

FIPS 140-2 certification is not fun. It probably takes a consultant and about a year to get a binary approved and if you change it, it has to be re-certified. Most folks seem to be content that your crypto-library is at least derived (i.e. patched) from a version that was certified. Good luck on your efforts there.

I'll try to get back to this soon.

Cheers,
Rick

[florian...@quantumedia.de]

Hi folks,

there is consensus that some algorithms/ciphers (e.g. RC4) allowed by default should not be considered secure, though because of interop issues, they cannot be removed at this point.

The problem with this is that people may think they are using a secure connection while in fact, someone could eavedrop. To reduce the impact of this problem, I propose to implement a visual indicator for when a connection should not be considered secure. The goal is not to show an OMG-BEWARE message but instead to not show a (falsy) "secure" indicator.

Currently, there is a padlock shown for HTTPS connections in Firefox (see first part of [1]). For insecure (but encrypted connections), there are three options:

A. Make it look like an HTTP connection: No padlock but the "world" icon, no "https:" string.

B. Indicate a broken padlock (e.g. with a big fat red bar crossing the padlock), show the "https:" string (like in the second part of [2]).

C. Make it look like an HTTP connection but not lie about the protocol: Use the globe icon but show the "https:" string (like part 3 of [1]).


(A) is lying but mostly obvious, i.e. it says that the user is not on an encrypted connection and should act accordingly. (C) is non-obvious because the globe can mean anything and the "https:" may confuse / mislead people who are used to looking for this string. (B) may not be completely obvious but it shows that there is something wrong although you are on an encrypted connection - I prefer this last option.


I understand that this is not dev.firefox but I think this is a solution that most can live with for the foreseeable future (this is no long-term solution!). Do you agree?

(The UI resolution can also be adopted for HTTP/2.0 unauthenticated HTTPS, and on any connection where the user bypassed any blocking mechanism, e.g. for failed cert checks. It may require changes to the identity panel as well to explain why the connection is shown as "unencrypted".)


Best regards,

Florian Bender


[1] http://imgur.com/C6wOlRm


Am Samstag, 14. Dezember 2013 07:48:01 UTC+1 schrieb marlen...@hushmail.com:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in functionality.

[Chris Newman]

As a non-Firefox/non-HTTP consumer of NSS, I'd like to see an NSS API flag
indicating a cipher suite is retained for backwards compatibility but
considered inferior by cryptographic community standards at the time the
NSS library was built.

A. is unacceptable because it breaks copy/paste of URLs

B. For UI, I'd suggest a ? over the padlock rather than a red bar. The
community believes RC4 may be vulnerable to high-skill attackers and is
likely to become more vulnerable to other attackers over time. That's
questionable security, not no security. It's still a lot better than
unencrypted (which is what you get if you remove RC4 prematurely).

C. The "https" URI scheme specifies the protocol not the policy so it
technically does not imply the connection is or will be secure. But I agree
this is non-obvious to at least some users and prefer option B.

Regardless, I think NSS should provide the flag, and Firefox can design the
UI.

- Chris

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

[Florian Bender]

Am Montag, 3. Februar 2014 22:50:38 UTC+1 schrieb Chris Newman:
> As a non-Firefox/non-HTTP consumer of NSS, I'd like to see an NSS API flag
> indicating a cipher suite is retained for backwards compatibility but
> considered inferior by cryptographic community standards at the time the
> NSS library was built.

Yes, awesome. That's the NSS-equivalent of my proposal.
Basically, there should be a definition for ciphers that says "ok" or "weak", exposed via API.

> A. is unacceptable because it breaks copy/paste of URLs

Copy/paste does some magic here (Firefox currently does not show "http://" but copies the complete URL string).

> B. For UI, I'd suggest a ? over the padlock rather than a red bar. The
> community believes RC4 may be vulnerable to high-skill attackers and is
> likely to become more vulnerable to other attackers over time. That's
> questionable security, not no security. It's still a lot better than
> unencrypted (which is what you get if you remove RC4 prematurely).

Hmm, good point. You have to think about your friend's parents, though, any not-entirely-obvious UI (even if it is actually correct) may confuse people.
But let's leave that to the UI team. My sketch was for illustratory purposes only.

> C. The "https" URI scheme specifies the protocol not the policy so it
> technically does not imply the connection is or will be secure. But I agree
> this is non-obvious to at least some users and prefer option B.

Most people are trained to look for "https:" on banking sites (because they were told that's how they identify a "secure connection"), so they may not see that the security on that connection is weak.
But again, UI is for UI team. ;)

> Regardless, I think NSS should provide the flag, and Firefox can design the
> UI.

Yes, I agree.


Best regards,

Florian Bender