Subject: Re: [TLS] DSS with other than SHA-1 algorithms

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Apr 2011 00:31:17 +1200

I've now posted a first draft for comment:

http://www.ietf.org/id/draft-gutmann-tls-eccsuites-00.txt

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 26 Apr 2011 19:12:52 +0200

> http://www.ietf.org/id/draft-gutmann-tls-eccsuites-00.txt

I have not implemented ECC ciphersuites, but the things
that striked me while reading it are:
* There is no mention of ECDHE_RSA or anon ciphersuites.
For me they are the most important as they optimize normal DH
using existing RSA certificates (in the _RSA case).

* A single ciphersuite negotiates the ECDHE parameters
AND the parameters of the ECDSA certificate. Could there
be cases where one can verify any ECDSA certificate, and
only his capabilities to ECDHE are restricted? In that
case it might be better to allow for any ECDSA certificate
rather than handling each different parameter
as different algorithm. (but I repeat I don't have an
overview of ECC in practice).

* It doesn't really need to be that aggressive with
the previous attempt. If this one is better/simpler it
will be used in practice and replace the old one. Maybe
some examples of failures of the current TLS-ECC-RFC
might be more convincing.

regards,
Nikos

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 27 Apr 2011 21:22:42 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>* There is no mention of ECDHE_RSA or anon ciphersuites. For me they are the
>most important as they optimize normal DH using existing RSA certificates (in
>the _RSA case).

Nothing (AFAIK) implements these.  The point of the RFC (draft) is to
standardise what are already de facto cipher suite configurations.  If nothing
uses them then they're not really de facto standard configs :-).

>* It doesn't really need to be that aggressive with the previous attempt. If
>this one is better/simpler it will be used in practice and replace the old
>one.

This doesn't replace the existing one, it complements it.  This profiles a set
of de facto standard cipher suites (rather than RFC 4492's Chinese menus) that
are already in common (well, as common as TLS-ECC gets anyway, which is to say
"not very") use.  The point is to have them standardised before TLS-ECC does
get common and the existing interop problems get worse.

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 27 Apr 2011 13:23:01 +0300

> overview of ECC in practice).

I could comment here, that both ECDSA signing and verification consist 
of ECC point multiplication and modulo operations. The ECDH operation on 
the other hand is a simple ECC point multiplication with no additional 
parameters. Therefore, if there is a case where one can verify an ECDSA 
certificate but his capabilities to ECDHE are restricted, the 
restrictions are completely artificial. Only thing coming to my mind 
would be some kind of proprietary or hardware based PKIX library 
supporting ECC but not offering an API to the low level ECC point 
multiplication. If someone knows about this kind of setup could us know 
now, but in my opinion it wouldn't make much sense...

Juho

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 28 Apr 2011 10:59:36 +0200

> get common and the existing interop problems get worse.

Thinking about it, it would be very IPSec to have two ways to do the
same thing.
If this method is intended to replace the current ECC draft, it should
specify how
the extensions are used once this draft is supported. I'd suggest to make it
mutual exclusive. If this draft is supported then the extensions are used to
negotiate unnamed curves only or so.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 28 Apr 2011 14:01:54 +0300

> negotiate unnamed curves only or so.

Before suggesting making the extensions only to be used for unnamed 
curves, it should be mentioned that RFC 4492 defines total of 25 named 
curves, of which this draft redefines only the 2 most commonly used. 
Also there are a lot of existing implementations out there that already 
implement ECC and many browsers have ECC turned on by default, most of 
them implement the suites listed in the draft. Making the draft mutually 
exclusive with existing ECC methods would make the transition almost 
impossible, causing more compatibility problems than it is trying to solve.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 30 Apr 2011 00:33:51 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>Thinking about it, it would be very IPSec to have two ways to do the same
>thing. If this method is intended to replace the current ECC draft, it should
>specify how the extensions are used once this draft is supported. I'd suggest
>to make it mutual exclusive. If this draft is supported then the extensions
>are used to negotiate unnamed curves only or so.

Uhh, that's exactly what the current draft does, see the two paragraphs
beginning "If no additional Chinese-menu ECC suites...".

Peter.