On Fri, Nov 1, 2013 at 2:22 AM, Kurt Roeckx <k...@roeckx.be> wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
>> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
>> > So what needs to happen so that we can move on with this?
>>
>> I still have the same question. Nothing seems to be happening.
>
> So it's been 2 months since the last discussion about this. Can
> we please move on?
Last week, we enabled TLS 1.2 in Firefox Nightly. Monday's Firefox
Nightly will enable AES-128-GCM and disable the SEED, ECDH, and
DSS_CAMELLIA cipher suites. Firefox Nightly will offer:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Basically, this is what I proposed in my proposal, with some Camellia
and 3DES cipher suites also mixed in, without AES-256-GCM (since NSS
doesn't support it yet), and in a different order. I filed bug 936828
[0]
During IETF88, we learned that the client hello-size-related
interoperability problems may have a very simple workaround; see [1]
and [2]. It is unclear if the workaround provided by F5 will fix all
the size-related ClientHello issues. There appears to be another
problem with Windows Server 2003 [3], but that problem seems unlikely
to affect NSS (at least Firefox) due to the relatively small number of
cipher suites we enable by default.
Last week, I also learned that ENISA, a European standards group,
recommends Camellia alongside AES as a future-proof symmetric cipher
algorithm; see [4]. I think we probably want to still disable Camellia
cipher suites by default in the long term anyway, but I did not
disable them in Firefox Nightly yet. In order for it to make sense to
continue offering Camellia cipher suites long term, we would need to
improve NSS's support for Camellia to add the ECDHE variants of the
Camellia cipher suites. Currently, I think the best course of action
is to let the current configuration ship, then disable Camellia
support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so
that it is ready in case some problem with AES is found.
In the IETF88 TLS WG meeting, EKR asked me to write up my proposal as
an internet-draft, so the next revision of the document will be in
that format. I will post it when it is ready.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=936828
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10445.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
[4]
https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report
Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
