TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

[martinthomson]

The IETF recommends TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, but it is not included in the intermediate configuration.

This is causing some people issues. In particular, those subject to security audits that use different reference material that includes server-side-tls find this to be problematic.

Note that DHE suites in TLS 1.2 are problematic. Clients cannot ensure that guarantee that safe groups are used unless they are willing to retry connections (which comes with its own risks). The TLS working group is discussing their deprecation, but has not reached a firm recommendation.

My suggestion is that we ignore the controversy until it resolves and restore consistency. Adding this suite to the intermediate configuration will fix the inconsistency.

[paulwouters]

gentle ping?

[ghen2]

Is there any client in the real world that does support TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 but does not support TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, which is preferred? If not, then this is not needed.

FYI: DHE ciphers TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and DHE-RSA-AES256-GCM-SHA384 are included because MSIE 11 only supports AESGCM with RSA+DHE or ECDSA+ECDHE, but not with RSA+ECDHE, strangely. That's why the cipher selection may seem inconsistent, but it's based on real-world experience.

[paulwouters]

Unfortunately, some security vendor is using this list to determine "unsafe" algorithms, and so now having TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is flagged as a security issue. Hence our request to make these consistent by either allowing this one or removing the other related ones as well. It will prevent us needing to make custom changes to the fedora/rhel system wide crypto policies which for obvious reasons are more consistent than this wiki page.

[gene1wood]

@martinthomson

It looks like TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, which is it's IANA name, is called DHE-RSA-CHACHA20-POLY1305 in OpenSSL and TLS_DHE_RSA_CHACHA20_POLY1305 in GnuTLS.

Currently TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256/DHE-RSA-CHACHA20-POLY1305 is present in the iana section of the old configuration level and in the openssl section of the old configuration level. It has been in the old configuration going back to before our v4.0 release.

Are you saying that we should add TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256/DHE-RSA-CHACHA20-POLY1305 to the intermediate configuration so that it will be present in both old and intermediate?

If so, do you have thoughts on where in the order of the intermediate iana and opensslciphers you'd like to see it (as I believe these ciphers are ordered by preference).

Or if I'm guessing wrong here, can you give more detail on where you're hoping to see this cipher show up (e.g. in our wiki page or in an example intermediate configuration for a given server software in our ssl config generator or somewhere else)

[martinthomson]

I would set "old" aside. Anything goes there. If I understand @paulwouters' concern, auditors probably regard "old" as "bad". And rightly so. So anything in "old" is meaningless. Everything is setup to push people toward "intermediate" anyway ("modern" is so narrow that you might make your site inaccessible; "old" is full of borderline insecure garbage).

So the request is to add this to "intermediate".

As for ordering, this is definitely a low priority suite, largely due to the use of ephemeral Diffie-Hellman (DHE) over the superior ECDHE. Copying its position from the "old" list over to "intermediate" would have it at the end after "DHE-RSA-AES256-GCM-SHA384", which is totally appropriate.

[ghen2]

I still fail to see a reason[*] to add a cipher that will never be negotiated in practice, as any client supporting it also supports ECDHE-RSA-CHACHA20-POLY1305, which you agree should be higher up in the priority list.
[*] besides perceived consistency or satisfying dumb security checks.

Contrary, the industry trend is to move away from DHE. Two other DHE ciphers are still included because it's the only way to negotiate AESGCM with MSIE11 on certain platforms, when not using ECDSA. But there's no such reason to add DHE-RSA-CHACHA20-POLY1305.

[gene1wood]

@martinthomson

Take a look at mozilla/ssl-config-generator#204 and #291 to see if that's what you're envisioning.

Here's a rendered version of the wiki page with the change](https://github.com/mozilla/server-side-tls/blob/59954f9f25f5e55900e90d9f8f0908164861fd13/Server_Side_TLS.mediawiki)

And here's the modification to the cipher list JSON file which powers the ssl-config-generator

[martinthomson]

the industry trend is to move away from DHE

Agreed. But the harm it causes is mostly just that it is slow.

There is probably room for a larger revision of the list that drops IE11 support entirely, given things like Win7 EOL and such, but that requires a bit more care and planning. A proper consideration of what "intermediate" means at the point that client support for TLS 1.3 is better (which is already the case for servers with a predominantly browser clients) is also worth adding to that.

[falconkirtaran]

I still fail to see a reason[] to add a cipher that will never be negotiated in practice, as any client supporting it also supports ECDHE-RSA-CHACHA20-POLY1305, which you agree should be higher up in the priority list. [] besides perceived consistency or satisfying dumb security checks.

Contrary, the industry trend is to move away from DHE. Two other DHE ciphers are still included because it's the only way to negotiate AESGCM with MSIE11 on certain platforms, when not using ECDSA. But there's no such reason to add DHE-RSA-CHACHA20-POLY1305.

I think the inconsistency is an issue, if only because it renders it difficult to exactly implement Mozilla's guidance if one also wants to use Fedora's requirements-based cryptography policy. Whether the security checks pass or fail is an issue (though I wish people would not use this compatibility guide as a security requirement). The future is that support for TLS 1.2 be dropped altogether and I don't imagine we're too many years away from that, but in the meantime I'd hate to see anyone disable chaha20-poly1305 just to make a PCI DSS scanner happy only because Fedora makes it difficult to support chacha20-poly1305 in TLS 1.3 but not TLS 1.2.

[gene1wood]

This is fixed in

#291
#293
mozilla/ssl-config-generator#204

I've built the ssl-config-generator and uploaded it.
I've deployed the updated wiki pages to wiki.mozilla.org