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

[Juho Vähä-Herttua <[e-mail]>]

On Apr 16, 2011, at 11:10 AM, Peter Gutmann wrote:
> Say you (i.e. the server) see, and select,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, as the best suite.  Then later in the
> exchange the client says, via an extension, that it wants to do P256, which

I'm sorry I probably wasn't clear enough in my message. I was trying to ask, when exactly will the client say that it wants to do P256? Are we talking about an exchange where the client doesn't send the elliptic_curves extension in its hello message? Because how I see the ECC handshake is pretty much like:

1. Client sends a ClientHello with elliptic_curves extension specifying its supported extensions
2. Server selects an ECC cipher suite and a curve that can be found in its supported curves list and client's supported curves list
3. Server sends its Certificate message which includes the curve OID of ECDSA public key (server might want to check that this can be found from elliptic_curves extension, but I'm still not quite sure that TLS should care about PKIX too much)
4. Server sends its ServerKeyExchange message which includes the curve it selected
5. Client uses the information from ServerKeyExchange and uses the same curve to send ClientKeyExchange

I tried to think of how this could be broken and could only think of the case where client doesn't send elliptic_curves extension. In that case it becomes really complicated, but doesn't seem so serious because it can be solved by simply sending the extension. And the specification could be MUCH more clear about all this, it took me quite a long time to find out how the ECC handshake should actually be done.

> In practice it's even worse than that, you can use completely different curves
> for the key exchange, to sign the key exchange, and for client auth, and for
> hashes it's nearly as bad.  What are you supposed to do if an implementation
> uses (say) P192 for the keyex signature but P521 for the keyex itself?  What
> security level do you treat this as being?  You can use the unnncessary

How is this different from using 1024-bit RSA keys for keyex signature but 2048-bit Diffie-Hellman keys for the keyex itself? It's a valid concern, but I don't see how it is ECC specific. And I like to keep PKIX and TLS separate, but some guidelines defining the security levels would be very useful.

> flexibility to make a complete mess of things, and from the little testing
> I've done almost anything you do that's slightly unusual results in a
> handshake failure or dropped connection, and I don't even want to try and see
> what happens when you start using the really odd capabilities, non-named
> curves and point compression and other oddities.

The non-named curves is a very strange feature, but I don't see it causing any harm. If someone needs to use it somewhere, it's nice that there's a defined and standard way to do it. I could imagine a need for something like that in proprietary implementations where the TLS implementations are only going to communicate with themselves and not any 3rd party software. The specification should be just made much more clear about what is actually used and what is there just because it might be useful some day. Now it doesn't make a clear difference, and as I already found out earlier a large part of the non-named curves is impossible to implement. (see RFC 4492 errata)

> So at the moment we already have a kind of de facto profile, mostly it seems
> to be P256+SHA256 everywhere, with optional P384+SHA384 everywhere, and I
> think I got away with P521 once or twice.  The single profile we have for ECC
> use with TLS, the Suite B one, already does this, it's 256-throughout (ECC
> keys and hashes) or 384-throughout (ECC keys and hashes).

I think I have seen 256+384+521 quite a lot, mostly because of the Suite B requiring 256 and 384. But I'm using TLS on some devices that simply don't have the processing capacity to do P-256 handshakes well. I tried to implement P-256 modular reduction, but first of all the key length is bigger and second the pseudo-Mersenne prime used in P-256 is 2^256 - 2^224 + 2^192 + 2^96 - 1. This means modular reduction needs 256/(256-224)=8 rounds and each rounds requires 4 addition operations. Compared with for example P-224 that uses prime 2^224 - 2^96 + 1 and requires just 2 rounds and 2 addition operations, the computational difference between the curves is much larger than the bit length would let one assume.

Sorry if I'm going too much into details here, but I'm simply trying to say that requiring support for P-256 might leave out a large number of devices with lower capabilities. But I think it would be fair to define that all implementations SHOULD implement at least P-256 and P-384, maybe also P-521 if it is considered useful. Now the specification is just giving a huge list of named curves with no idea about what curves are actually used, even though pretty much all of the implementations are just using two or three of them. That's not right.


Juho