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

From: [email-masked]
Date: Tue, 02 Dec 2014 05:26:29 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Author          : Yoav Nir
	Filename        : draft-ietf-tls-rfc4492bis-00.txt
	Pages           : 31
	Date            : 2014-12-02

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Elliptic Curve
   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
   authentication mechanism.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 02 Dec 2014 14:48:41 +0100

Sections 6:

    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.

It makes more sense to require both server implementations and client 
implementations to support at least one of 
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA or 
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA and at least one of 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA or 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, and recommend servers to be 
configured to accept either TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA and 
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA or 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, and recommend clients to offer at 
least one.

On 2014-12-02 14:26, [email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 02 Dec 2014 15:34:27 +0100

> certificate and one EC certificate.
I think this is not a problem since the text is about server _implementations_
not actual server deployment.

I'm more concerned about the choice of ECDH as opposed to ECDHE for the first
two ciphersuites.

Manuel.

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 02 Dec 2014 18:05:32 +0100

On 2014-12-02 15:34, Manuel Pégourié-Gonnard wrote:
> I think this is not a problem since the text is about server_implementations_

Well, it is a problem if the standard allows fully conformant clients to 
only support cipher suites that require the server to choose RSA 
certificates, because that rules out conformant servers to be deployed 
with only EC certificates.

> I'm more concerned about the choice of ECDH as opposed to ECDHE for the first

Good point.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Dec 2014 17:40:33 +0000

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

> 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.

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 02 Dec 2014 19:05:35 +0100

> ECDSA and RSA certificates.

Fair enough, but is it really an acceptable outcome that a fully 
conformant server (that is deployed with only RSA certificates) and a 
fully conformant client (that only implements one of the mandatory ECDSA 
cipher suites) will not be able to negotiate a connection?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Dec 2014 18:19:57 +0000

On Tue, Dec 02, 2014 at 07:05:35PM +0100, Henrick Hellstr?m wrote:

> Fair enough, but is it really an acceptable outcome that a fully conformant
> server (that is deployed with only RSA certificates) and a fully conformant
> client (that only implements one of the mandatory ECDSA cipher suites) will
> not be able to negotiate a connection?

This document does not replace the mandatory to implement cipher
suites in TLS 1.x.  So the client and server MUST still both offer
the usual (RSA-based) MTI cipher suites for each version of TLS
they support.

The text in question provides additional ciphersuites that conformant
implementations SHOULD support.  So in your example, a client that
suports ECDH(E) only with ECDSA, will employ neither EC based key
agreement nor EC based authentication.  The various MTI cipher
suites don't require either.

This said, perhaps the asymmetry between the client and server
requirements deserves more explanation.

-- 
	Viktor.

---

From: Sean Turner <[email-masked]>
Date: Tue, 2 Dec 2014 16:40:24 -0500

> the usual (RSA-based) MTI cipher suites for each version of TLS

This is correct - RFC 4492 didn’t change the MTI cipher suites for TLS1.0-1.2 and since 4492bis is just an update it won’t change the MTI cipher suites either.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Dec 2014 08:35:05 -0500

Yoav,

I’m sure this is on your list but just in case somebody thinks these are coming out of nowhere: please ensure that the errata are addressed:
http://www.rfc-editor.org/errata_search.php?rfc=4492&rec_status=15&presentation=table

Thanks,

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Dec 2014 08:35:05 -0500

Yoav,

Thanks,

spt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 Dec 2014 16:20:13 +0200

OK.

> On Dec 4, 2014, at 3:35 PM, Sean Turner <[email-masked]> wrote:
> 
> Yoav,
>