Re: [TLS] draft-gutmann-tls-eccsuites

[Henrik Grubbström <[e-mail]>]

Hi Peter et al.

On Mon, Jul 7, 2014 at 2:56 PM, Peter Gutmann <[e-mail]> wrote:
> Speaking of ECC drafts, I've posted an updated version of my ECC ciphersuites
> draft, now with the Brainpool curves added:
>
> http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-06

Hmm...

>From the above draft section 2:

| If no additional Chinese-menu ECC suites are used, implementations
| SHOULD NOT send the Supported Elliptic Curves or Supported Point
| Formats extensions since these parameters are fully specified by the
| suite choice.

Have you considered the following note in RFC 4492 section 5.1?

| NOTE: A server participating in an ECDHE-ECDSA key exchange may use different
| curves for (i) the ECDSA key in its certificate, and (ii) the
ephemeral ECDH key in the
| ServerKeyExchange message. The server must consider the extensions
in both cases.

As I read the above, your suites would default to imply extra
restrictions on the possible server certificates, as you would be
restricted to only the same curve as in the suite (eg you wouldn't be
able to use a SECP521 cert with
TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384, as the server
wouldn't know if the client was capable of verifying the cert).

The server can probably safely assume that the client supports
certificates for all the curves in the client hello suites, but this
doesn't help with certs using curves not in the list of suites in the
draft.

Or is the intent of the draft that the server just should select a
cert and hope for the best?

Anyway, the intended ECDSA certificate policy ought to be made
explicit in the draft.

/grubba

--
Henrik Grubbström                                       [e-mail]
Roxen Internet Software AB                              [e-mail]