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

From: "Don Sturek" <[email-masked]>
Date: Thu, 6 Jan 2011 06:36:59 -0800

I wanted to bring up the draft presented by David McGrew last July (in
Maastricht) one more time.  The draft (now expired I think) is  "AES-CCM ECC
Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00.

I know there was a thread last summer on this.  I am part of the ZigBee
Alliance implementing TLS for an IEEE 802.15.4 application.   We would like
the TLS group to consider (or maybe re-consider though I never saw any
formal disposition of this on the reflector) the use of David's draft for
IEEE 802.15.4 networks.

I think CCM is a common cipher suite for IEEE802 and this draft matches what
is specified in IEEE (and implemented in hardware in millions of devices).

Thanks,

Don Sturek

---

From: Russ Housley <[email-masked]>
Date: Thu, 6 Jan 2011 09:45:14 -0500

I am willing to work with David McGrew on this document if there is WG interest in producing an RFC for this ciphersuite.

Russ

On Jan 6, 2011, at 9:36 AM, Don Sturek wrote:

>  
> I wanted to bring up the draft presented by David McGrew last July (in Maastricht) one more time.  The draft (now expired I think) is  "AES-CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00.
>  
> I know there was a thread last summer on this.  I am part of the ZigBee Alliance implementing TLS for an IEEE 802.15.4 application.   We would like the TLS group to consider (or maybe re-consider though I never saw any formal disposition of this on the reflector) the use of David’s draft for IEEE 802.15.4 networks.
>  
> I think CCM is a common cipher suite for IEEE802 and this draft matches what is specified in IEEE (and implemented in hardware in millions of devices).
>  
> Thanks,
> 
> Don Sturek

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 6 Jan 2011 16:52:51 +0200

> I know there was a thread last summer on this.  I am part of the ZigBee Alliance implementing TLS for an IEEE 802.15.4 application.   We would like the TLS group to consider (or maybe re-consider t…

The discussion thread can be seen in http://www.ietf.org/mail-archive/web/tls/current/msg06716.html and the main problems are pretty much mentioned in the later post http://www.ietf.org/mail-archive/web/tls/current/msg06761.html

Basically the proposed draft should probably be divided into smaller parts. One part would define the AES-CCM cipher suites in a way that would be interoperable with existing TLS cipher suites. Another part would describe the use of TLS and AES-CCM in IEEE 802.15.4 networks, including forbidding the use of other than ECDSA certificates and forbidding the elliptic_curves and ec_point_formats extension.

> I think CCM is a common cipher suite for IEEE802 and this draft matches what is specified in IEEE (and implemented in hardware in millions of devices).

From what I can tell, the draft was not interoperable with existing cipher suites for no apparent reason (other than that's how ZigBee uses it). But if that can be fixed then there should be no problem including AES-CCM in TLS.

Juho

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 6 Jan 2011 07:09:28 -0800

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.  

Picking up on parts of the thread noted above, I would say the main reason
to consider CCM rather than GCM is simply because it is part of the IEEE802
standards and there is hardware support for CCM in currently deployed
chipsets (many millions of them to date with many more millions on order).
To employ GCM, we would have to bypass the CCM hardware support and
implement GCM in software then get IEEE to re-consider CCM for later
revisions of standards.

The only concern that I saw with the draft is the truncation issue in this
part of the thread:
http://www.ietf.org/mail-archive/web/tls/current/msg06724.html.   There is
even a suggestion within on how we might get around this issue for small RAM
size devices like IEEE 802.15.4 solutions.

Don

-----Original Message-----
From: Juho Vähä-Herttua [mailto:[email-masked]] 
Sent: Thursday, January 06, 2011 6:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again)

Alliance implementing TLS for an IEEE 802.15.4 application.   We would like
the TLS group to consider (or maybe re-consider though I never saw any
formal disposition of this on the reflector) the use of David’s draft for
IEEE 802.15.4 networks.

The discussion thread can be seen in
http://www.ietf.org/mail-archive/web/tls/current/msg06716.html and the main
problems are pretty much mentioned in the later post
http://www.ietf.org/mail-archive/web/tls/current/msg06761.html

Basically the proposed draft should probably be divided into smaller parts.
One part would define the AES-CCM cipher suites in a way that would be
interoperable with existing TLS cipher suites. Another part would describe
the use of TLS and AES-CCM in IEEE 802.15.4 networks, including forbidding
the use of other than ECDSA certificates and forbidding the elliptic_curves
and ec_point_formats extension.

> I think CCM is a common cipher suite for IEEE802 and this draft matches
what is specified in IEEE (and implemented in hardware in millions of
devices).

>From what I can tell, the draft was not interoperable with existing cipher
suites for no apparent reason (other than that's how ZigBee uses it). But if
that can be fixed then there should be no problem including AES-CCM in TLS.

Juho

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 6 Jan 2011 17:48:56 +0200

> (http://www.ietf.org/mail-archive/web/tls/current/msg06718.html) are all

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