TLS 1.3 ciphers and protocol values

[tomato42]

Especially for openssl cipher string, the TLS1.3 cipher names could already be added.

In general, we should have a plan when the TLS 1.3 is published as a standard RFC.

[concatime]

By now, there is a hell mess between TLS1.3 draft-18 and draft-20 in OpenSSL. Majors browsers use the draft-18. So, we could only wait until the final release.

Currently OpenSSL has implemented the “draft-20” version of TLSv1.3. Many other libraries are still using older draft versions in their implementations. Notably many popular browsers are using “draft-18”. This is a common source of interoperability problems. Interoperability of the draft-18 version has been tested with BoringSSL, NSS and picotls.

Source.
See https://github.com/RaymiiOrg/cipherli.st/issues/82

[concatime]

See previous comment.

[tomato42]

If you have a server with draft-20 support and browser that has draft-18 support they will simply negotiate TLS1.2. I don't see how this is "interoperability hell"...

Just don't disable TLS1.2 and you're fine.

[gene1wood]

@tomato42 Could you clarify what change your suggesting in the wiki page or the config generator?

[tomato42]

add

TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256

to the list of ciphers in all the versions.

For the wiki page, declare them as

          0x13,0x02 - TLS13-AES-256-GCM-SHA384 TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD                                       
          0x13,0x03 - TLS13-CHACHA20-POLY1305-SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD                      
          0x13,0x01 - TLS13-AES-128-GCM-SHA256 TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD

[icing]

Need an update on this. For Apache httpd, I have code in trunk that scrapes the Mozilla JSON and makes "modern/intermediate/old" config options for the server.

Without any changes, this would mean you want TLSv1.3 disabled for "modern"? How is this supposed to be phased in?

[tomato42]

no, TLSv1.3 should be enabled for modern

the general for the policies is that Old is a proper superset of Intermediate and Intermediate is a proper superset of Modern

and there's no point in disabling in in Old so it should be part of all three

[icing]

In your head maybe. Not in Mozilla's JSON from curl https://statics.tls.security.mozilla.org/server-side-tls-conf.json

...
    "configurations": {
        "modern": {
            "openssl_ciphersuites": ...,
            "ciphersuites": [...],
            "tls_versions": ["TLSv1.2" ],
...

[jvehent]

The final RFC for TLS1.3 has not been published yet. I think we should wait for that, and maybe some more, before adding it to the guidelines. Early adopters can tweak their configs, but the majority shouldn't rush in.

…

On Wed, Mar 28, 2018, 06:47 Stefan Eissing ***@***.***> wrote: In your head maybe. Not in Mozilla's JSON from curl https://statics.tls.security.mozilla.org/server-side-tls-conf.json ... "configurations": { "modern": { "openssl_ciphersuites": ..., "ciphersuites": [...], "tls_versions": ["TLSv1.2" ], ... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZXgcbfWpHrwb5Rh_qdOjLf2PPhKlBiks5ti2pBgaJpZM4NXBV-> .

[lukastribus]

The ciphers for TLS1.3 are defined and draft28 has been approved. None of this will change in a way that would impact the Mozilla recommendation.

When OpenSSL 1.1.1 is released, and TLSv1.3 has not been specifically disabled by the application, but the cipher configuration won't contain TLSv1.3 ciphers, OpenSSL will fail for all TLS version completely. So upgrading to OpenSSL 1.1.1 will break existing setups with Mozilla recommendations.

So if there is consensus about not implementing TLSv1.3 recommendations now, we should then explicitly suggest to disable TLSv1.3.

@tomato42 "old" contains most recent TLSv1.2 AEAD ciphers like ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-ECDSA-AES128-GCM-SHA256, old must contain everything that is in modern as well. The entire point of this recommendation is that "old" configuration does not break modern software stacks which may not even have obsolete ciphers anymore.

[jvehent]

When OpenSSL 1.1.1 is released, and TLSv1.3 has not been specifically disabled by the application, but the cipher configuration won't contain TLSv1.3 ciphers, OpenSSL will fail for all TLS version completely.

That sounds like a terrible idea. Why would openssl decide to do this?

[tomato42]

#191 (comment)

In your head maybe

can you go and be rude somewhere else?

#191 (comment)

@tomato42 "old" contains most recent TLSv1.2 AEAD ciphers like ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-ECDSA-AES128-GCM-SHA256, old must contain everything that is in modern as well. The entire point of this recommendation is that "old" configuration does not break modern software stacks which may not even have obsolete ciphers anymore.

that's what I said... If something is in Modern, it needs to be in all three, exactly so that Old configuration is the most compatible, Intermediate less so and Modern least so

#191 (comment)

That sounds like a terrible idea. Why would openssl decide to do this?

likely because disabling TLS 1.3 based on cipherstring would be more surprising

[jvehent]

likely because disabling TLS 1.3 based on cipherstring would be more surprising

A valid argument, yet I wonder if this will block a massive rollout of openssl 1.1.1 due to large amount of configurations breaking.

[icing]

Well, in my very limited testing, I enabled TLSv1.3 in addition to the setting specified as Mozilla modern on my Apache and old openssl curls talked TLSv1.2 and new ones TLSv1.3 - as it should be.

If you see other results in your settings, please let us know.

[lukastribus]

Apparently the reason is:

All connections will fail so that you quickly notice that the cipherspec does not include any ciphers permitted by TLS 1.3, which is a bug in your invocation.

This "design choice" is final:

openssl/openssl#5057
openssl/openssl#5065

So either we add the recommended TLSv1.3 everywhere, or if we decide to wait, we have to suggest to everyone to disable TLSv1.3.

I strongly suggest the former (adding "TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384" to the top of the recommendations).

@jrchamp @tomato42 yes indeed I misunderstood the point you made.

[jvehent]

To be clear: I'm in favor of adding TLS1.3 to the guidelines. I just want to be mindful about when, to make sure we don't break people's configurations while draft implementations are still out there. Ultimately, I don't think waiting another month or two isn't going to change anything. The OpenSSL incompatibility issue changes this a bit.

[icing]

I said: "In your head maybe (but the JSON says otherwise)"
You: "can you go and be rude somewhere else?"

This was not intended to be rude. What I meant was that the machine readable specification does not match what you think it should be. I'd like to get an understanding of what it needs to be, so that code may act accordingly and correctly, before we ship it to millions of sites.

I agree with you that TLSv1.3 should be in modern, but at the moment it is not. And if Mozilla wants to maintain authority here (and I think it should), then it needs to state very clearly what and how TLSv1.3 applies.

[tomato42]

machine readable specification does not match what you think it should be

I opened this issue to add them there, of course I know they're not there

[icing]

Misunderstood you there. Sorry for the wasted cycles.

[tomato42]

@lukastribus while I remember reading about this behaviour before I can't reproduce it now

with current master (openssl/openssl@e6e9170) when I run openssl s_client -cipher 'HIGH:!AESGCM:!eNULL' against a default s_server, I negotiate TLS_AES_256_GCM_SHA384, and I see all 3 TLS 1.3 ciphers (AES-128-GCM, Chacha20 and AES-256-GCM) on the wire

From what I can see, there's a separate API call needed to change behaviour in TLS 1.3: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html

Same for the s_client tool, with -ciphersuites affecting only TLS 1.3

[lukastribus]

@tomato42 HIGH contains TLSv1.3 ciphers so this is expect. Use the mozilla recommendation (with specific non-TLSv1.3 ciphers, not groups like HIGH) to hit this issue.

To be clear and avoid any additional misunderstandings: what I am saying is that OpenSSL 1.1.1 will break with the current Mozilla recommendation, and your proposal resolves this.

[tomato42]

@lukastribus actually no, it is not part of HIGH since openssl/openssl#5392

with current master openssl s_client -cipher ECDHE-RSA-AES128-GCM-SHA256 will negotiate TLS 1.3 and TLS_AES_256_GCM_SHA384

I've filed openssl/openssl#5777 to fix the blog post

[ekr]

It seems like there are two separate issues here:

1. Should we recommend TLS 1.3
2. How do we avoid recommending inconsistent configurations

Based on the discussion here, I have to say I'm a bit unclear on whether our current recommendations break OpenSSL. If not, I think it's fine -- indeed perhaps preferable -- to delay recommending TLS 1.3 until the RFC is published. OTOH, if we have to change our recommendations anyway, this requires more thought. So maybe we can get consensus on the facts first?

[lukastribus]

@tomato42 I see, thanks. And indeed this change fixes the breakage caused by OpenSSL 1.1.1 behavior. So they did change their opinion on this after all, which is good.

@ekr correct; now there is consensus though about the breakage, which was fixed by OpenSSL later on.

So forget what I said about OpenSSL 1.1.1; also there is no rush at this point to consider TLSv1.3 ciphers.

In fact the opposite is the case. as @tomato42 noticed, OpenSSL now has a different API to configure TLSv1.3 ciphers (SSL_CTX_set_ciphersuites()). So actually applications will need to implement this new API and will therefor have to expose a different configuration option to the user. So I'd argue that it doesn't make sense to merge TLSv1.3 with TLS <= 1.2 ciphers in the Mozilla recommendation then, as it will be a different config knob in the application anyway.

Sorry for the outdated informations here, I didn't expect the OpenSSL team to do a 180 on this what looked like a "final design decision" ...

[icing]

So, my understanding of this:

• if you enable TLSv1.2 with OpenSSL, all things stay as before, ciphers configuration included.
• if you enable TLSv1.3 as protocol and nothing else, that protocol version defaults to ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
• if you want specific 1.3 ciphers, you have to use SSL_CTX_set_ciphersuites() to do so.

So 1.2 and 1.3 have separate protocol config sets (at least for ciphers) and those need to be configured separately. So, I better add a config directive to set the ciphers for TLSv1.3 then.

[richsalz]

Yes, OpenSSL changed behavior after alpha-test results came in and showed that what we were doing was not good. So yay, the process worked. :) Because the TLS 1.3 ciphers are really very very very different from everything before them, we decided it is better to have them be handled separately. If TLS 1.3 is enabled, then by default all TLS 1.3 ciphers are enabled (slightly different from @icing's bullets above). Applications that want to disable some of them, or change the order, need to use a new API or command-line flags. So yeah, making a separate config directive is the way I would do it.
Hope this helps.

[gene1wood]

I'll close this as it sounds resolved, if I'm mistaken please let me know and clarify what remains to be done.

[tomato42]

No, the TLS 1.3 ciphers are not described in the document, so it's not resolved

[april]

This is fixed in 5.0.