Thank you Hubert from starting this discussion. I think this can be the
base for version 4 of the document.
On 2014-10-20 08:10, Hubert Kario wrote:
The items that probably should be changed or added:
* curves weaker than secp256r1 - I think they shouldn't be
enabled at all - while browsers do enable only the two or three
NIST curves, clients that use OpenSSL enable also the rather weak
163 bit curve, making it possible to negotiate them (and as such
limit the level of security to about 80 bit)
I agree. The document currently recommends secp256r1, secp384r1 and
secp521r1. It would be good to have a more comprehensive list of curves,
and have another list of discarded curves in the "Mandatory discards"
section. The problem is being able to specify these curves in
configurations, which isn't widely supported in servers.
* negotiation of curves in ECDHE - servers in general should
be able to negotiate the used curve for this KEX - it's a RFC MUST
Could you clarify what you mean by 'negotiate' ? Do you mean that
servers should implement configurable lists of supported curves?
* lack of secp256r1 intolerance - servers that hardcode this
curve may ignore the tls extension completely, causing the
connection
to fail if the client doesn't support this curve (the server
should
choose a cipher that doesn't require ECC in such case)
This is the same problem we have with 2048 DHE parameters and Java 6,
where the client fails the handshake instead of falling back to a
non-DHE cipher. In this situation, I believe that the role of the guide
is to inform operators on the issue and what configuration they should
pick.
Servers should patch their TLS stacks, but that's hardly something we
can address in the wiki...
* SHA1 signing of (EC)DHE in TLSv1.2 - there's a bug in OpenSSL that
causes the SNI certificate selection to not copy acceptable
signature
algs properly, this causes it to sign the key exchange using SHA1.
Some servers may just hardcode the sig alg, which would be just as
bad
That is also a server problem. What do you propose we add to the
document to address this?
* SHA-384 and SHA-512 signatures in certs - in current version
they are not acceptable - as they are stronger, I think they
should
be added as acceptable (but maybe marked as not recommended).
SHA-224 should probably be explicitly marked as non recommended as
it is not supported in some libraries that do support SHA-256 and
greater (very old NSS had this issue)
I'm not against, modulo verification that these signatures work with
all the intended clients described in "Oldest compatible client" of each
level. We should also list the clients that are not compatible.
I wonder if this is really useful though. Server Side TLS is a
pragmatic guide, and pragmatism dictates that operators should use
SHA-256 certs, not SHA-384 or SHA-512. When asked to review a production
site that runs a SHA-512 cert, I would recommend the admins to downgrade
to SHA-256 to prevent unknown behavior with unknown clients.
* ECDSA certs (and prioritisation of ECDSA above RSA) - there's no
mention of those, and since we suggest PFS over non-PFS and
ECDHE-ECDSA is over twice as fast as ECDHE-RSA[1], I think we
definitely should allow (if not recommend) its use
Same comment as above: we first need to evaluate compatibility of
clients.
Having ECDSA in the recommended ciphersuites has no site effect on
server compatibility. But recommending ECDSA certificates does have
strong side effects.
Do you know of certificate authorities that issue ECDSA certs?
* intolerance of TLS1.3 ClientHello - new version is incoming
while a significant percentage of servers can't do TLS version
negotiation properly
Let's leave this aside for now. TLS1.3 will not be implemented for many
more months, and we don't know much about its structure yet. I don't
want to confuse operators with recommendations that don't map to
anything yet.
While most of those items may become issues only in future, I think
it's better to point to them now, so that the number of
servers that have bad configurations/bugs is limited. As such,
it will also limit the need for clients to do the TLS downgrade
dance.
I never envisioned Server Side TLS as an implementation guide. I always
thought of it as an operation guide. Many of your comments imply that we
need a modern and reliable TLS implementation guide for servers, which I
agree with, but maybe that should be a separate document that can dive
into sample code and coding guidelines?
Even better, something similar to the Configuration Generator, but for
code: http://mozilla.github.io/server-side-tls/ssl-config-generator/
I agree that we need to cover more of TLS, but we also must keep the
guidelines focused on what operators need to know and can use quickly.
- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
