Subject: [TLS] No algorithm specified for server to pick cipher suite in TLS standards

From: "Sommer, Tilman" <[email-masked]>
Date: Fri, 12 Nov 2010 15:01:58 +0100

Neither in RFC5246 nor its predecessors, there seems to be
no algorithm specified how the server should pick the cipher suite 
to be used in the "server hello" message.

Indications I found in the internet said that the server would
pick the "strongest" cipher suite of the intersection, 
which spawns the question about how the strength of a cipher 
suite is ultimately determined.

Key length of the encryption key is not a good indicator,
since the strength of algorithms may be judged differently over time
when vulnerabilities are detected, so I would think
the best option is to leave the order of precedence up to
the server's administrator.

- Tilman

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 15 Nov 2010 00:42:43 -0800

> to be used in the "server hello" message.

This is best left up to the server administrator (as you note below).
When a client sends its hello message containing a list of cipher
suites, it is basically saying to the server, "any of these is fine,
pick one."

If the client thinks a particular cipher suite is not secure enough,
then it can easily exclude it from the list it includes in the Client
Hello.

Note that the client has the ability to control which cipher suite is
selected -- it just needs to send the single cipher suite that it
actually wants (though it may have to probe the server to determine
which suites are supported).

> suite is ultimately determined.

Security is not always the most important factor.  Some servers are
configured to always choose RSA-RC4-128-SHA if the client offers it
anywhere in the list.  Most likely this is for performance reasons,
whether it actually makes a difference.  Many sites have also turned
off DHE-based cipher suites due to the extra processing it requires
(over RSA) despite the fact that RSA does not provide forward secrecy.

What is most important is that TLS is used at all, whatever the cipher
suite.  It is much easier to go after the unencrypted traffic on a
network than to try to break the crypto.  (Assuming an extremely weak
export-grade cipher is not used of course.)

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Nov 2010 15:21:05 +0100 (MET)

> the server's administrator.

Yes, that is rougly it.

The client has the privilege to propose a set of "acceptable" cipher suites,
and the server has the privilege to select a common cipher suite from
the intersection of what the client offers and what the server prefers.

Although some SSL&TLS implementations (including OpenSSL) had originally
used the client-offered list of cipher suites taking precendence over
the server's list, most implementation today probably have the
servers preference list taking precedence over the one sent by the
client.

Unless the server admin configures his preferred cipher suites, there
is probably a default preference provided by whatever TLS implementation
is used for the server, or a default preference requested by the
application.  Performance seems to be one of the concerns (as you can
see from TLSv1.2 with the SHA256-based PRF not being enabled by default
on newer Microsoft Platforms).

Traditionally, the SSL_RSA_WITH_RC4_128_* have the best performance,
and SSL_RSA_WITH_3DES_EDE_CBC_SHA is much slower.
TLS_RSA_WITH_AES_128_CBC_SHA (rfc3268) is probably somewhere between
the two (for pure software-based crypto).  Some newer CPUs have
crypto hardware-support for specific algorithms or algorithm primitives
(ultrasparc T2, PowerPC, Intel Core i*), so depending on which of
those features can be actually used by server TLS implementations
the relative performance among TLS cipher varies.

In contrast to SSLv2, the integrity protection traffic keys are not
artificially limited in SSLv3/TLS, but depend primarily on the
hash algorithm that is used and the keysize of the server credential
and the keysize of the key pair that is used for the key exchange
(key agreement).  For vanilla RSA cipher suites, it is only the keysize
of the server credential, as that is used for key exchange.

-Martin