-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server Side TLS v5.0 #183
Server Side TLS v5.0 #183
Conversation
* HSTS: '''max-age=15768000''' | ||
* Certificate switching: '''None''' | ||
* Versions: '''TLSv1.3, TLSv1.2''' | ||
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I would recommend x448, given that Firefox doesn't do it. @davidben, does Chrome?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope.
(Is that intended to be a preference order? Putting RFC 7748 after NIST curves is odd.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree on ordering, SafeCurves first please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if nothing supports it right now, x448 is our only standard-driven, SafeCurve option above x25519. If the server does not support it, it should just skip over it, but the sooner we start pushing for it, the sooner support will be available on both the server and client side. Given that, if this set of recommendations is not the right place for advocating what's next, then I would understanding delaying its inclusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x25519
should be preferred, but it also should be optional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that x25519, p256, and p384 are fine here. x448 might be awesome in theory, but it's not awesome in practice and we shouldn't tell people to put the effort in for things that they won't get.
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' | ||
* Certificate type: '''ECDSA (recommended) or RSA''' | ||
* Certificate curve: '''prime256v1, secp384r1''' | ||
* Certificate signature: '''ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would nail the curves to the hashes TLS 1.3 style
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we shouldn't dedicate at least a paragraph to RSA-PSS signatures and certificates...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These here are right; you want these in the certificate, and I think that we can rely on TLS stacks to get the PSS thing right. While text on PSS might help, it's probably not going to get the results you want (we might see PSS certificates, which won't work).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might see PSS certificates, which won't work
they do work in OpenSSL and GnuTLS already; NSS is also slowly progressing towards that direction
* Certificate type: '''ECDSA (recommended) or RSA''' | ||
* Certificate curve: '''prime256v1, secp384r1''' | ||
* Certificate signature: '''ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption''' | ||
* Certificate transparency: '''required''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why you're requiring this, but in any case it's not specific enough to tell people what to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, an explanation what it is and how it's handled is needed
* Bits of security: '''>=112''' (RSA 2048 and above, P-256, P-384) | ||
* DH Parameter size: '''2048''' (recommend using [#Pre-defined_DHE_groups Pre-defined DHE groups]) | ||
* HSTS: '''max-age=15768000''' (6 months) | ||
* HPKP: '''max-age=2589000''' (1 month) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's your rationale for lowering these values.
Also see comments above which apply here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, don't see a reason to lower them in the intermediate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't be recommending HPKP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @martinthomson, the world is moving away from HPKP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack. I'll remove it altogether.
* HSTS: '''max-age=15768000''' | ||
* Certificate switching: '''None''' | ||
* Ciphersuites: '''ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS''' | ||
* Versions: '''TLSv1.3, TLSv1.2, TLSv1.1, TLSv1''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why needs TLSv1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what it's worth, if you are getting rid of TLSv1, consider dropping TLSv1.1 as well given there are very few clients/servers that have a max version of TLSv1.1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because close to 20% of android phones are still on version that does not enable/support TLS1.2 (that is Android earlier than 4.3): https://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/
* Certificate switching: '''None''' | ||
* Ciphersuites: '''ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS''' | ||
* Versions: '''TLSv1.3, TLSv1.2, TLSv1.1, TLSv1''' | ||
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The curve selection and ordering discussion in Modern applies here as well.
* HSTS: '''max-age=15768000''' | ||
* Certificate switching: '''None''' | ||
* Versions: '''TLSv1.3, TLSv1.2''' | ||
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x25519
should be preferred, but it also should be optional
* HSTS: '''max-age=15768000''' | ||
* Certificate switching: '''None''' | ||
* Ciphersuites: '''ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS''' | ||
* Versions: '''TLSv1.3, TLSv1.2, TLSv1.1, TLSv1''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because close to 20% of android phones are still on version that does not enable/support TLS1.2 (that is Android earlier than 4.3): https://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/
* Ciphersuites: '''ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS''' | ||
* Versions: '''TLSv1.3, TLSv1.2, TLSv1.1, TLSv1''' | ||
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' | ||
* Certificate type: '''ECDSA (recommended) or RSA''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for intermediate, I think we should recommend ECDSA and RSA - dual cert deployment - or RSA alone
* Bits of security: '''>=112''' (RSA 2048 and above, P-256, P-384) | ||
* DH Parameter size: '''2048''' (recommend using [#Pre-defined_DHE_groups Pre-defined DHE groups]) | ||
* HSTS: '''max-age=15768000''' (6 months) | ||
* HPKP: '''max-age=2589000''' (1 month) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, don't see a reason to lower them in the intermediate
* HPKP: '''max-age=34387200''' (13 months) | ||
* Certificate Validity: '''<=398 days''' (13 months) | ||
* OCSP Stapling: '''required''' | ||
* CAA: '''recommended''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CAA
is not explained in the document
* Certificate type: '''ECDSA (recommended) or RSA''' | ||
* Certificate curve: '''prime256v1, secp384r1''' | ||
* Certificate signature: '''ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption''' | ||
* Certificate transparency: '''required''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, an explanation what it is and how it's handled is needed
</source> | ||
|
||
Rationale: | ||
* ChaCha20 is prefered as the fastest and safest in-software cipher, followed by AES128. Unlike the modern configuration, we do not assume clients support AESNI and thus do not prioritize AES256 above 128 and ChaCha20. There has been discussions ([http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html 1], [http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg12398.html 2]) on whether AES256 extra security was worth its computing cost in software (without AESNI), and the results are far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks. | ||
* DES-CBC3-SHA and EDH-RSA-DES-CBC3-SHA are maintained for backward compatibility with clients that do not support AES. | ||
* DHE is removed entirely because it is slow in comparison with ECDHE, and all modern clients support elliptic curve key exchanges. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said in #178 (comment) use of DHE can be valid.
* Certificate signature: '''ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption''' | ||
* Certificate transparency: '''optional''' | ||
* Bits of security: '''>=112''' (RSA 2048 and above, P-256, P-384) | ||
* DH Parameter size: '''2048''' (recommend using [#Pre-defined_DHE_groups Pre-defined DHE groups]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to use DH parameters, even though we don't use DHE in the intermediate level anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Time to think about shipping this. TLS 1.3 is going to RFC very soon.
* Bits of security: '''>=112''' (RSA 2048 and above, P-256, P-384) | ||
* DH Parameter size: '''2048''' (recommend using [#Pre-defined_DHE_groups Pre-defined DHE groups]) | ||
* HSTS: '''max-age=15768000''' (6 months) | ||
* HPKP: '''max-age=2589000''' (1 month) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't be recommending HPKP.
* HSTS: '''max-age=15768000''' | ||
* Certificate switching: '''None''' | ||
* Versions: '''TLSv1.3, TLSv1.2''' | ||
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that x25519, p256, and p384 are fine here. x448 might be awesome in theory, but it's not awesome in practice and we shouldn't tell people to put the effort in for things that they won't get.
* TLS curves: '''prime256v1, secp384r1, x25519, x448''' | ||
* Certificate type: '''ECDSA (recommended) or RSA''' | ||
* Certificate curve: '''prime256v1, secp384r1''' | ||
* Certificate signature: '''ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These here are right; you want these in the certificate, and I think that we can rely on TLS stacks to get the PSS thing right. While text on PSS might help, it's probably not going to get the results you want (we might see PSS certificates, which won't work).
Is it too soon to mention EdDSA? It seems like a very good option, for software that provides it as an option. |
Does any common CA issue EdDSA certs?
…On Thu, Aug 9, 2018 at 6:36 AM, Jonathan Champ ***@***.***> wrote:
Is it too soon to mention EdDSA <https://tools.ietf.org/html/rfc8410>? It
seems like a very good option, for software that provides it as an option.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#183 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABD1oanZNIblVmX0T-ETBo1LE56UhhB0ks5uPDrngaJpZM4MQ7x->
.
|
Not for public trust certs at least; Edwards curves aren't approved in the BRs yet. |
In that case, yes, I think it's premature/
…On Thu, Aug 9, 2018 at 7:06 AM, Clint Wilson ***@***.***> wrote:
Not for public trust certs at least; Edwards curves aren't approved in the
BRs yet.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#183 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABD1oXzLhvj8QBnhyEs-blL3TreKx0Meks5uPEH7gaJpZM4MQ7x->
.
|
now it's about 4.4% of Android phones that can't connect to TLS 1.2 servers, and with the recent discussions on IETF TLS WG ML, we may actually be able to push for TLS 1.1 and TLS 1.0 deprecation (allow them only in "Old") |
Mind if I close this in favor of #255? |
Closing due to obsolescence. |
This is the result of the discussion from #178
It's not ready to merge yet, but summarizes the goals of this new version. Please discuss.