Re: Cipher suits, signature algorithms, curves in Firefox

[Hubert Kario]

On Friday 06 May 2016 10:34:37 Zoogtfyz wrote:
> > the larger key size helps w.r.t. quantum computers.
> 
> If quantum computers are currently on the level of breaking AES-128,
> then they are on the level of breaking any asymmetric cryptography
> (RSA, DHE or ECDHE key exchange) we are using - which makes support
> for AES-256 moot.

That's not correct.

Grover's algorithm requires you to perform 2^(n/2) operations to break 
symmetric crypto, and it uses n qbits to do that. To break aes-128 you 
need quantum computer with 128 qbits, and 2^64 operations. To break 
AES-256 you need 256 qbits and 2^128 operations.

To break RSA you need quantum computer which can do Shor's algorithm, 
which requires n*3/2 qbits and around (log n)^2 operations. So for 2048 
bit RSA you need 3072 qbit QC and about 83 operations.

In other words, quantum computer that breaks AES-128 can't even scratch 
RSA. Quantum computer that breaks AES-256 doesn't make it possible to 
actually recover plaintext, and it still don't break currently used RSA.

> Moving away from AES-256 will put even more
> pressure on the crypto community to come up with a solution as
> opposed to the *relative* complacency we are seeing now.

I don't think we are in the position to demand crypto community to do 
anything in particular...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Julien Pierre]

Zoogtfyz,


On 5/6/2016 07:34, Zoogtfyz wrote:
Websites that prefer AES-256, such as internal websites, can always 
instruct their users/customers to toggle a switch in Firefox to enable 
AES-256. I am proposing having AES-256 ciphersuits toggled off by 
default. 

IMO, that is impractical. I would recommend against doing this.

It was discussed on the Chrome mailing list. They are not yet enabled by 
default in Chrome stable, it is not yet decided if/when it will be enabled.
Nevertheless, other AES-256 cipher suites are already enabled in 
Chrome.  I don't think anyone is proposing to remove those from Chrome. 
MO, we should not remove any AES-256 cipher suites from Firefox/NSS.
I would agree with the proposal to reorder them, however, and prioritize 
AES-GCM over AES-CBC. Since application developers may have different 
opinions about priority order of cipher suites, I think it would be 
helpful to implement the following 2 NSS ERs which I filed recently :


https://bugzilla.mozilla.org/show_bug.cgi?id=1267894
https://bugzilla.mozilla.org/show_bug.cgi?id=1267896

Only the first one is related to Firefox, but both are related.

There are other considerations to take into account other than "strength".
Indeed, and those considerations might be application-specific, or 
hardware-specific, which is why I think the above 2 ERs make sense to 
implement.


When it comes to signature algorithms and curves, IMO, there should be 
some runtime support for configuring them and prioritizing them.
Right now, AFAIK, we don't have any kind of runtime configuration for 
either. Both are hardcoded at compile-time. IMO, it is time for this to 
change.
We should have at the very least runtime APIs to to enable/disable 
curves and enable/disable signature algorithms.  Several other libraries 
already offer this.


Preferably, we should also have a configurable ordered list for those, 
as I'm proposing we add for cipher suites.


Julien



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

Re: Cipher suits, signature algorithms, curves in Firefox

[Zoogtfyz]

Brian Smith wrote:

> A lot of people have interpreted what I wrote as saying AES-256 is bad.
I was not really referring to what you wrote about AES-256. I was referring to 
for example https://eprint.iacr.org/2009/374 . Even though those are related 
key attacks (which should not be relevant to *proper* implementation in TLS), 
it gets people worried about the constructions in AES-256 compared to AES-128. 
We should be moving away from AES as it is currently standardized, due it's 
small number of rounds anyway (the internal NSA version of AES uses a larger 
number of rounds).

> the larger key size helps w.r.t. quantum computers.
If quantum computers are currently on the level of breaking AES-128, then they 
are on the level of breaking any asymmetric cryptography (RSA, DHE or ECDHE key 
exchange) we are using - which makes support for AES-256 moot. Moving away from 
AES-256 will put even more pressure on the crypto community to come up with a 
solution as opposed to the *relative* complacency we are seeing now.

> the larger key size helps in preventing some multi-user attacks.
Given relatively widespread hardware acceleration, it makes no difference 
regarding AES-128 compared to AES-256.

> Even if we think that these merits are small, others do dot think they are 
> small.
And as is too often the case, people get crypto wrong :)

> and so there will always be websites that prefer AES-256.
Websites that prefer AES-256, such as internal websites, can always instruct 
their users/customers to toggle a switch in Firefox to enable AES-256. I am 
proposing having AES-256 ciphersuits toggled off by default.

> Also, with AES-NI and similar optimizations on CPUs, AES-256 is not too much 
> slower than AES-128.
My concerns are not much with respect to performance. AES-NI are common on 
desktops, but most mobile devices are not yet ARMv8 so they don't get hardware 
acceleration.

> the ECDHE-AES-256-GCM cipher suites should be added to Firefox.
They will be added to NSS, just to have support for them. The question is 
whether they will be toggled on by default in Firefox.

> they were just recently added to Google Chrome.
It was discussed on the Chrome mailing list. They are not yet enabled by 
default in Chrome stable, it is not yet decided if/when it will be enabled.

> if people want non-ECC DHE cipher suites, then at a minimum we need to define 
> new cipher suite IDs.
What is likely happening is new TLS extension to advertise support for that. In 
the meantime, we should not support DHE - note that Chrome stable currently 
does not advertise support for DHE ciphersuits (but they have a fallback 
mechanism).

> There are other considerations to take into account other than "strength".
True. My proposal is just something to change in the meantime while waiting for 
TLSv1.3. Most of these suggestions would help with a smoother transition to 
TLSv1.3 once it's out. Regarding the signature algorithms, supporting the ones 
that Chrome supports and ordering them the same way can help with 
hard-to-track-down compatibility issues, while we wait for TLSv1.3. Personally, 
I would even get rid of the SHA512 algorithms, but removing those does break 
*few* not *none* websites.

> Is your test data set and code available somewhere? It sounds interesting.
I will put in a request with legal on Monday to get the code opensourced and 
data publicly available. It will have to be redacted though, because it 
contains TLS applications that are accessible over the internet, but likely 
should not be public (such as many mailservers, xmpp servers, irc servers, 
webcams, and other applications running on non-standard ports).

I used a subset of the data, only considering TLS servers running on TCP port 
443, with a properly resolving DNS name, with a valid certificate for that 
domain (valid and trusted according to Firefox 45esr). In this subset of data, 
no new handshake errors were introduced by my proposed changes.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Martin Thomson]

On Fri, May 6, 2016 at 10:12 AM, Peter Bowen  wrote:
> Is a reasonable path to implement
> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 and
> treat ECDHE suites as being DHE using a Supported Group?  This would
> avoid new cipher suite IDs and accomplish the same result.

I'm implementing it now.  Not because we need it for TLS 1.2 (where
it's not clear that it is 100% safe), but because we need it for TLS
1.3.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Martin Thomson]

On Fri, May 6, 2016 at 9:33 AM, Brian Smith  wrote:
> So, I don't think that dropping AES-256 is the right thing to do. Instead,
> the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that
> they were just recently added to Google Chrome.

These are also coming to NSS, likely in 3.25 (Firefox 49 if everything
goes to plan).  Supporting different PRF hashes (we need SHA-384 for
those suites) turns out to be a little bit intrusive.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Peter Bowen]

On Thu, May 5, 2016 at 4:33 PM, Brian Smith  wrote:
> Zoogtfyz  wrote:
>>
>> 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly,
>> most often with default common DH primes, DH parameter reuse, or generally
>> weak bitstrenght (equivalent to 1024bit RSA, which is already considered
>> insecure in Firefox). Hence it's better to remove support for DHE (not
>> ECDHE) cipher suits rather than give false sense of security.
>>
>
> I agree. I think if people want non-ECC DHE cipher suites, then at a
> minimum we need to define new cipher suite IDs for them that imply keys of
> at least 2048 bits. Unless/until that happens, they are more trouble than
> they are worth.
>
> Note that Chrome recently reached the same conclusion.

Is a reasonable path to implement
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 and
treat ECDHE suites as being DHE using a Supported Group?  This would
avoid new cipher suite IDs and accomplish the same result.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Brian Smith]

Zoogtfyz  wrote:

> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and everything
> works as advertized. I used Firefox telemetry data, SSL Pulse data, and my
> own tests to verify that *not a single* publicly accessible website would
> get handshake errors compared to today.
>

Awesome.

>
> Reasoning:
> 1) Too many people put 256bit CBC cipher suits at higher priority than
> 128bit AEAD cipher suits because they don't know what they are doing.
>

Agreed.


> 2) 256bit AES cipher suits have known issues compared to 128bit AES cipher
> suits. It is not well studied yet how much those issues apply to the cipher
> suit implementation in TLS. Given that 256bit GCM cipher suits will not be
> added to Firefox, it is better to disable 256bit AES cipher suits
> completely.
>

When I the part of https://briansmith.org/browser-ciphersuites-01 regarding
AES-256, I didn't do a good job. A lot of people have interpreted what I
wrote as saying AES-256 is bad or worse cryptographically than AES-128.
That isn't what I meant to write. AES-256 still has some significant
advantages over AES-128. In particular, the larger key size helps w.r.t.
quantum computers. Further, the larger key size helps in preventing some
multi-user attacks. Even if we think that these merits are small, others do
not think they are small, and so there will always be websites that prefer
AES-256. Also, with AES-NI and similar optimizations on CPUs, AES-256 is
not too much slower than AES-128.

So, I don't think that dropping AES-256 is the right thing to do. Instead,
the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that
they were just recently added to Google Chrome.


> 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly,
> most often with default common DH primes, DH parameter reuse, or generally
> weak bitstrenght (equivalent to 1024bit RSA, which is already considered
> insecure in Firefox). Hence it's better to remove support for DHE (not
> ECDHE) cipher suits rather than give false sense of security.
>

I agree. I think if people want non-ECC DHE cipher suites, then at a
minimum we need to define new cipher suite IDs for them that imply keys of
at least 2048 bits. Unless/until that happens, they are more trouble than
they are worth.

Note that Chrome recently reached the same conclusion.


> Additionally, Firefox 45esr currently supports these signature algorithms
> in this ordering:
> SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA,
> SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA
>
> I recommend changing it to these in this ordering:
> SHA512/ECDSA, SHA512/RSA, SHA384/ECDSA, SHA384/RSA, SHA256/ECDSA,
> SHA256/RSA, SHA1/ECDSA, SHA1/RSA
>

I suggest you read the text that Google's David Benjamin added to the TLS
1.3 draft regarding this.

Also, see
https://groups.google.com/d/msg/mozilla.dev.security.policy/smAUN2Rtc78/EuQoSyvmAwAJ
where I argued something similar.

Reasoning:
> 1) *not a single* publicly accessible website uses DSA (not ECDSA)
> signatures anymore.


I agree DSA should be dropped


> 3) Ordering from strongest to weakest, as opposed to what it is today.
>

There are other considerations to take into account other than "strength",
as David Benjamin's proposal and my suggestion linked above show.


> Additionally, Firefox 45esr currently supports these elliptic curves in
> this ordering:
> secp256r1, secp384r1, secp521r1
>
> I recommend removing support for secp521r1 since it is not supported in
> the wild, Chrome does not support it, and we should be moving away from
> secp curves to e.g. x25519. Once again, *not a single* publicly accessible
> website breaks with this change.
>

I agree. See https://bugzilla.mozilla.org/show_bug.cgi?id=1128792.

Is your test data set and code available somewhere? It sounds interesting.

Cheers,
Brian
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Gervase Markham]

On 05/05/16 15:22, Zoogtfyz wrote:
> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and
> everything works as advertized. I used Firefox telemetry data, SSL
> Pulse data, and my own tests to verify that *not a single* publicly
> accessible website would get handshake errors compared to today.

We went through the process of evaluating this 1-2 years ago; I recall
Brian Smith was involved. If people can dig up the old messages or bugs,
it would make it easier to interact with new suggestions.

Gerv

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

Cipher suits, signature algorithms, curves in Firefox

[Zoogtfyz]

This is my recommendation for changes to the supported ciphersuits in Mozilla 
Firefox. I performed rigorous compatibility testing and everything works as 
advertized. I used Firefox telemetry data, SSL Pulse data, and my own tests to 
verify that *not a single* publicly accessible website would get handshake 
errors compared to today.

Firefox 45esr currently supports these ciphersuits in this ordering:
C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013 TLS_ECDHE_RSA_WITH_AES_128_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
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

I recommend changing it to these in this ordering:
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
002F TLS_RSA_WITH_AES_128_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

Reasoning:
1) Too many people put 256bit CBC cipher suits at higher priority than 128bit 
AEAD cipher suits because they don't know what they are doing.
2) 256bit AES cipher suits have known issues compared to 128bit AES cipher 
suits. It is not well studied yet how much those issues apply to the cipher 
suit implementation in TLS. Given that 256bit GCM cipher suits will not be 
added to Firefox, it is better to disable 256bit AES cipher suits completely.
3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly, most 
often with default common DH primes, DH parameter reuse, or generally weak 
bitstrenght (equivalent to 1024bit RSA, which is already considered insecure in 
Firefox). Hence it's better to remove support for DHE (not ECDHE) cipher suits 
rather than give false sense of security.
4) Additionally, once chacha20 lands in Firefox, move it to top.

If we wanted to be even more strict, we could change the supported cipher suits 
to these in this order:
C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
002F TLS_RSA_WITH_AES_128_CBC_SHA
000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

Reasoning:
1) Still *not a single* publicly accessible website gets handshake errors 
compared to today - because we still have the two backwards compatible cipher 
suits. (002f and 000a).
2) It puts additional pressure on server operators to support AEAD cipher suits 
if they want ECDHE ciphersuits.

Overall, this once again limits the number of ciphersuits in the wild, and 
makes it easier to remove supported weak ciphersuits from server applications.

Additionally, Firefox 45esr currently supports these signature algorithms in 
this ordering:
SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, 
SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA

I recommend changing it to these in this ordering:
SHA512/ECDSA, SHA512/RSA, SHA384/ECDSA, SHA384/RSA, SHA256/ECDSA, SHA256/RSA, 
SHA1/ECDSA, SHA1/RSA

Reasoning:
1) *not a single* publicly accessible website uses DSA (not ECDSA) signatures 
anymore.
2) This brings it in line with Chrome.
3) Ordering from strongest to weakest, as opposed to what it is today.

Additionally, Firefox 45esr currently supports these elliptic curves in this 
ordering:
secp256r1, secp384r1, secp521r1

I recommend removing support for secp521r1 since it is not supported in the 
wild, Chrome does not support it, and we should be moving away from secp curves 
to e.g. x25519. Once again, *not a single* publicly accessible website breaks 
with this change.

Thank you for your consideration.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto