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

From: Peter Gutmann <[email-masked]>
Date: Tue, 8 Jul 2014 11:55:31 +0000

Henrik Grubbström <[email-masked]> writes:

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

Yep, and that's a feature, not a bug.  The ambiguity over what's what is one
of the (numerous) problems with the current use of ECC in TLS, the eccsuites
draft nails it down to a single, unambiguous choice (currently this is done
implicitly by implementations following set of de facto "profiles" as
described in the draft, but the draft makes this explicit).

(It could also be argued that using a P256 cert with a P521 curve, or vice
versa, or some similar combination doesn't make much sense, why authenticate a
521-bit keyex with only a 256-bit signature?).

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

The intent is that the security of the curve used for keyex match the curve
used in the cert, and that there's just a single unambiguous choice for that.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 8 Jul 2014 08:58:27 -0400 (EDT)

----- Original Message -----
> From: "Peter Gutmann" <[email-masked]>
> To: "<[email-masked]>" <[email-masked]>
> Sent: Tuesday, July 8, 2014 1:55:31 PM
> Subject: Re: [TLS] draft-gutmann-tls-eccsuites
> 
> >| 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.
> >
> versa, or some similar combination doesn't make much sense

Currently there are no P256 root CA certs in Mozilla trust store. That would
force all users to use P384 leaf certificates, and by extension the AES-256 GCM,
which is unsupported by NSS (and unlikely to be actually needed by vast
majority of users).

>, why authenticate a

long term offline vs short term mitm attack. Or in other words, breaking
the 256 bit signature will compromise the authentication part of the connection,
breaking the 521 bit keyex will compromise the confidentiality.

Unrelated to the above:
The draft specifies few TLS1.1-and-lower compatible cipher suites, e.g.:
TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA
My understanding is that you can't use anything but concatenation of MD5|SHA1
for signing the key exchange with TLS1.1-and-lower. Am I missing something
or does it apply only the hash used for digital signatures in certificates?

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [email-masked]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: [email-masked] (Martin Rex)
Date: Tue, 8 Jul 2014 17:16:14 +0200 (CEST)

> or does it apply only the hash used for digital signatures in certificates?

The concatenation of MD5|SHA1 applies only to RSA-signatures
(in digitally signed PKCS#1 v1.5 (block type 2?)) in TLSv1.1 and earlier.

For (EC)DSA, it is traditionally SHA1-only (r+s integers).
But there is a general rule about acceptable hash algorithms for
use with (EC)DSA keypairs, and the key parameters are normally
chosen in a fashion that implies a minimum length of the hash output
(either SHA-1 or one of the SHA-2 algorithms).  rfc4492 says that
the hash could be something other than SHA-1, which I would read as
use the minimum hash length as implied by the (EC)DSA key parameters.

-Martin