Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt

[Viktor Dukhovni <[e-mail]>]

On Tue, Dec 02, 2014 at 02:48:41PM +0100, Henrick Hellstr?m wrote:

>    Server implementations SHOULD support all of the following cipher
>    suites, and client implementations SHOULD support at least one of
>    them:
> 
>    o  TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
>    o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
>    o  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>    o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
> 
> Isn't this recommendation problematic? I don't think it is very common for
> servers to have more than one certificate, and a server can't support all
> four of these cipher suites, unless it has both one RSA certificate and one
> EC certificate.

Given the far from universal support for ECDSA by clients, a server
that wants to use ECDSA when possible, but still wants to interoperate
with more than just a select few clients really SHOULD have both
ECDSA and RSA certificates.

The main reason it is not common for servers to have more than one
certificate is that generally they have only RSA certificates,
which have (practically) universal support.

For what it is worth, Postfix (via OpenSSL) supports simultaneous
deployment of both RSA and ECDSA keys/certs.  In the near to medium
term, any server that wants to deploy ECDSA should also deploy RSA,
to avoid interoperability issues with a sizeable fraction of clients.

-- 
	Viktor.