TLS_ECDHE_ECDSA cipher suites

[Takahiko Kawasaki]

Financial-grade API Implementer's Draft 2, Part 2, 8.5. TLS considerations, permits the following 4 cipher suites only. These match the ones recommended in 4.2. Recommended Cipher Suites of BCP 195.

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

In addition to the above, the following should be permitted unless there are reasons to exclude ECDSA intentionally.

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Regarding technical details, please refer to:

1. Bulletproof SSL and TLS
2. 2.3 User Secure Cipher Suites in SSL and TLS Deployment Best Practices

[Nat Sakimura]

Need to dig into the reasons BCP195 is excluding them.

[Ivan Ristic]

Unfortunately, BCP195 is excluding ECDSA keys while not providing an explanation. This is unusual, as many prefer ECDSA for an increased security margin as well as better performance.

I reviewed the current draft and here are my thoughts about what you should consider:

• ECDSA keys are widely used and it’s not obvious why they would be excluded.
• The “Read-Only API Security Profile” spec recommends TLS 1.2 with certificate checking, but I think it should do more, specifically to require preference for (or even exclusive use of) forward security and AEAD suites.
• I think that “Read and Write API Security Profile” has tried to do something along these lines, but it has a serious problem: TLS 1.3 is the current best protocol version, but because of the protocol changes, no longer supports any of the whitelisted suites. The net effect is that the use of TLS 1.3 is non-compliant.
• Whitelisting suites (and all other crypto elements) is tricky because improvements are made over time to address the weaknesses of existing elements. Still, given that it’s very unlikely that TLS 1.2 will get new suites, going with TLS 1.3 or better and allowing TLS 1.2 with selected suites should be workable.

[Takahiko Kawasaki]

Dear @Ivan Ristic ,

// For those who don' know: Ivan is the author of “Bulletproof SSL and TLS”, definitely an expert in this area.

Thank you very much for your professional comment. “The net effect is that the use of TLS 1.3 is non-compliant.” is a shocking reality.

Regarding “TLS 1.2 with selected suites”, could you show us a concrete list? For example, do you think the following is good?

‌

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

‌

Our final goal is to make the section “8.5. TLS considerations” more appropriate for financial-grade security. If you kindly improve the description of the section (or rewrite it from scratch if necessary), it would be really appreciated.

[Joseph Heenan]

Hi Ivan,

Many thanks for taking the time to read and comment, it is greatly appreciated.

The problem you raise with part 2 & TLS 1.3 seems very real; I’ve raised a separate new issue to make sure that is addressed:

https://bitbucket.org/openid/fapi/issues/248/part-2-text-prevents-the-use-of-tls-13

[Ivan Ristic]

Takahiko, that’s a good list, but the recommendation should be to deploy the suites with server preference configured and in the following order:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

With the above, there are some edge cases with IE11 on Windows 7, I don’t know if that’s within your scope.

Additionally, only strong key exchange parameters should be used (e.g., well-known 2048-bit DH parameters, secp256r1 for EC; stronger named groups optional).

For sake of completeness, there are also ChaCha20 AEAD suites that are considered strong, but they’re relatively new and not the conventional choice https://tools.ietf.org/html/rfc7905

[Dave Tonge]

We should email the relevant working group to get confirmation on this list and then update the spec.

[Nat Sakimura]

Did you email, @Dave Tonge ?

[Ralph Bragg]

@Dave Tonge with the wording that’s been applied on the pull request we’re essentially taking on responsibiltiy for TLS cipher concerns. Working with a number of banks they do tend to bang on about the BCP as being definitive. We can certainly make the case for TLS 1.3 being deemed to be secure and not relvent / profiled by the working group but it would be great if we could get the BCP updated rather than having to maintain this section. In the same way as if something develops with TLS 1.3 i’d expect a that WG to create a BCP for TLS 1.3 security.

Finally, if we are going to completely maintain this section and own it then shouldn’t we do as Ivan has suggested and really “own it” and provide guidance on the lot including key exchange parameters? At the moment it feels like a half way house.

[Dave Tonge]

I propose we close this - as we now allow TLS 1.3….

I agree with Ralph that I don’t think this WG should have this concern

[Dave Tonge]

We agreed on the call to close this issue