Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again)

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

On 6.1.2011, at 17.09, Don Sturek wrote:
> Hi Juho,
> 
> On your very last sentence, could you elaborate on why you think the draft
> is not interoperable with other cipher suites?  I think topics like those
> discussed in this part of the thread
> (http://www.ietf.org/mail-archive/web/tls/current/msg06718.html) are all
> very easy to resolve.  

I think the issues are pretty easy to solve as well. The first thing that came into my mind about not being interoperable was the extension part:

      The client MUST NOT offer the elliptic_curves extension nor the
      ec_point_formats extension.  The server MUST NOT expect to receive
      those extensions.

The client offering AES-CCM cipher suites should be allowed to offer other cipher suites as well. Those other cipher suites may need to define elliptic_curves or ec_point_formats extensions, but AES-CCM draft forbids offering them. That's a clear conflict. Another smaller issue was the certificate part:

      The server's certificate MUST contain an ECDSA-capable public key,
      and it MUST be signed with ECDSA.  If a client certificate is
      used, the same conditions apply to it.

I don't see a reason why a cipher should restrict the type of certificates, although requiring the ECDSA-capable public key in ECDSA cipher suite is kind of obvious. This is not really conflicting, but it would be much nicer if the AES-CCM would be defined as a generic cipher that can be used with any kind of certificate and the additional IEEE 802.15.4 related restrictions would be in a separate document. It works for all the other ciphers and RSA, DHE_DSA or DHE_RSA or certificates signed with some other signing algorithm are not really less secure than ECDSA. I guess the reason for this is again to simplify the hardware implementation by only using ECDSA for everything.


Juho