Subject: [TLS] AES-CCM ECC Cipher Suites for TLS @ IETF 78

From: David McGrew <[email-masked]>
Date: Fri, 16 Jul 2010 14:54:06 -0700

Hi,

I would like to request a time slot the TLS meeting at IETF78 to  
describe "AES-CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- 
ecc-00, and how it could be useful in TLS.  This work aims to provide  
a ciphersuite suitable for compact implementations and use in  
bandwidth-challenged environments.  It was developed with input from  
the Zigbee Smart Energy 2.0 task group.

A related work-in-progress that I'd like to mention is "The Compressed  
X.509 Certificate Format", draft-pritikin-comp-x509-00, which is  
intended for similar environments.  I can give a one-slide overview of  
this work and how it relates.

regards,

David

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 16 Jul 2010 17:56:30 -0500

David McGrew wrote:
> I would like to request a time slot the TLS meeting at IETF78 to describe
"AES-
> CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00, and how
it
> could be useful in TLS.  This work aims to provide a ciphersuite suitable
for
> compact implementations and use in bandwidth-challenged environments.  It
> was developed with input from the Zigbee Smart Energy 2.0 task group.
> 
> X.509 Certificate Format", draft-pritikin-comp-x509-00, which is intended
for
> similar environments.  I can give a one-slide overview of this work and
how it
> relates.

Some TLS implementions (e.g. Microsoft, and soon OpenSSL and NSS) have
already shipped AES-GCM implementations, specialized CPU instructions for
AES-GCM seem to be on the verge of becoming ubiquitous on end-user systems
(e.g. Intel AES-NI), it is possible to build fast and constant-time AES-GCM
implementations with only SIMD instructions, and AES-GCM is or will be
required for some government applications of TLS (e.g. NSA Suite B profile
for TLS). So, I think every mainstream TLS implementation is going to
implement the AES-GCM cipher suites.

Basically the opposite of all that is true for CCM. So, what are CCM's
advantages over GCM and why can't/shouldn't devices implement the AES-GCM
cipher suites to enhance interoperability with mainstream TLS
implementations? I heard that CCM can be implemented in software with a
smaller number of opcodes, so that is one reason. But, how many fewer
opcodes does it need? Are you expecting that it will become commonplace for
mainstream (e.g. desktop, web server, mobile phone) TLS implementations to
support these CCM cipher suites?

Section 2 tries to impose restrictions on clients and servers which would
reduce interoperability. For example, "The client MUST NOT offer the
elliptic_curves extension nor the ec_point_formats extension.  The server
MUST NOT expect to receive those extensions." I guess this must be an
attempt to limit ECC patent exposure, but IMO that doesn't belong in the
document defining these cipher suites. Surely any TLS client that implements
these cipher suites and indicates support for curves the server supports
should work. After all, some other servers (that implement other
ciphersuites) might be able to use those extensions or even require them.

Why did you define new cipher suites instead of defining an extension like
the Truncated HMAC extension?

Regards,
Brian

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sat, 17 Jul 2010 15:15:00 +0300

> ciphersuites) might be able to use those extensions or even require them.

I don't think those belongs in this draft either. How can a cipher suite 
define that those extensions are a "MUST NOT offer" when the extensions 
in question are defined in a completely separate RFC? I agree that the 
elliptic_curves and ec_point_formats extensions should be clarified and 
using the secp curves mentioned should be highly recommended, but I 
doubt this is the right document to do that.

> the Truncated HMAC extension?

This truncation and usefulness of it is what I asked in a private email 
earlier, but didn't get a reply. I think it is ugly and reserves too 
many cipher suite codes, it also makes the implementation slightly more 
difficult. I agree that an extension would be better if it really is 
considered necessary.

Juho

---

From: David McGrew <[email-masked]>
Date: Mon, 19 Jul 2010 05:35:15 -0700

Hi Brian,

thanks for the comments,

On Jul 16, 2010, at 3:56 PM, Brian Smith wrote:

>> describe
>> intended

Thanks for the summary of the GCM ciphersuite implementation status,  
it is great to hear the level of support we might get.

> support these CCM cipher suites?

Good questions.  AES-CCM is a good choice for inexpensive, low-power  
radio devices in general and 802.15.4 devices in particular.  It is  
the mode of operation used for 802.11i and 802.15.4 link-layer  
security, so an AES-CCM ciphersuite enables .15.4 devices to multi- 
purpose that implementation.  It is this pragmatic point that  
motivated the interest in CCM.

Here is a quick comparison of CCM and GCM:

GCM requires implementation of the AES forward (encrypt) operation and  
a GF(2^128) multiplier.  CCM requires only the AES forward (encrypt)  
operation.

A CCM circuit can be more compact, because it doesn't need a GF(2^128)  
multiplier.  Existing hardware for low-power radio devices typically  
lacks the GF(2^128) multiplier.   GCM would use a bit less power than  
CCM, FWIW.

Similar considerations apply to software implementations.  CCM need  
implement only the AES forward encrypt operation, while GCM needs to  
implement that function plus the multiplier.

GCM is ideal for high throughput implementations because it can be  
pipelined.  CCM in contrast can't be pipelined because it uses a  
chaining mode of operation.  This benefit is not compelling to low- 
power radio applications, though.

Within the low-power radio community, there is probably an expectation  
that the CCM ciphersuite does not need universal support; it would be  
adequate if servers for that application environment supported it.

> ciphersuites) might be able to use those extensions or even require  

A major goal for this draft is to define a public-key ciphersuite for  
TLS that is suitable for compact implementations in minimum-bandwidth  
environments, so it selects a narrow subset.    It would be  
unreasonable to expect a compact implementation to support all 25  
curves (plus two arbitrary curves) and multiple alternate  
representations for each curve.  An essential function of this draft  
is to identify the appropriate subset of curves, which is an aid to  
interoperability for compact implementations.   This draft in no way  
limits full implementations of RFC 4492, and thus doesn't affect their  
interoperability.

A secondary but important goal is to align with Suite B and  
fundamental-ecc.  The ECC choices in the draft match the MUSTs in  
RFC4492 and match Suite B.

> the Truncated HMAC extension?

I'm not sure I understand the question - we need a new ciphersuite to  
use CCM.

Some of the considerations regarding key exchange and other things  
that facilitate compact implementations could be written up  
separately.  Were you suggesting something like that?   Or perhaps I  
misunderstood your point.

regards,  	

David

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Mon, 19 Jul 2010 19:52:47 +0300

19.7.2010 15:46, David McGrew kirjoitti:
>> I don't think those belongs in this draft either. How can a cipher 
>> suite define that those extensions are a "MUST NOT offer" when the 
>> extensions in question are defined in a completely separate RFC?
>
> The intent of the draft was to define a subset of of RFC4492 key 
> exchange by referencing that RFC, and then defining the MUSTs and MUST 
> NOTs.   This should be a perfectly "legal" thing to do.  If it is not 
> clear, then we could either rework the exposition, or we could copy 
> the subset of RFC4492 that is used into the draft, so that the 
> description is self contained.

I think it should be at least reworked a bit, because I think it 
conflicts with RFC 4492 a little bit. So I'll iterate through the MUSTs 
and MUST NOTs here shortly:

--- AES-CCM draft quote ---
The curves secp256r1, secp384r1, and secp521r1 MUST be supported;
these curves are equivalent to the NIST P-256, P-384, and P-521
curves. Note that all of these curves have cofactor equal to one,
which simplifies their use.
--- end of quote ---

This is quite ok, but it could be changed into something like: "MUST be 
supported by any implementation of AES-CCM cipher suites". This way it 
would be more clear that it doesn't affect any other cipher suites.

--- AES-CCM draft quote ---
The uncompressed point format MUST be supported, and other point
formats MUST NOT be used. The use of other point formats will be
considered in later versions of this draft.
--- end of quote ---

The first MUST is ok, and in fact the RFC 4492 also already defines that 
the uncompressed point as the default and as something that MUST be 
supported. That MUST NOT clause is a bit strange, since the draft itself 
says that the use of other point formats will be considered in later 
versions. I would prefer if it would be written as "other point formats 
SHOULD NOT be used with AES-CCM cipher suites". This way it would not 
conflict with the later versions nor the RFC 4492, but only supporting 
uncompressed format would still be highly recommended.

--- AES-CCM draft quote ---
The client MUST NOT offer the elliptic_curves extension nor the
ec_point_formats extension. The server MUST NOT expect to receive
those extensions.
--- end of quote ---

Here's the part I have problem with. The client_hello is sent before the 
used cipher suite is negotiated, which means that the client can offer 
other ECC cipher suites (defined in RFC 4492) in addition to AES-CCM 
cipher suites. What RFC 4492 says about the elliptic_curves and 
ec_point_formats extensions:

--- RFC 4492 quote ---
The extensions SHOULD be sent along with any ClientHello message that
proposes ECC cipher suites.
--- end of quote ---

Now if I want to implement both RFC 4492 and AES-CCM draft, it seems 
like these two specifications are in conflict with each other. 
Personally I would probably leave that paragraph out completely from the 
draft, since even if the extensions are sent, they are not causing any 
harm. Optionally it could be rewritten into something like:

If the client sends the elliptic_curves extension, it MUST contain the 
values 23 (secp256r1), 24 (secp384r1) and 25 (secp521r1).

This sentence would surely be compatible with RFC 4492 and other ECC 
cipher suites. If you want to make it clear that other curves should not 
be used, it could be specified in the earlier paragraph.

> I sent a private note - let me know if it makes sense, and we can 
> bring it to the list if it does.

You're right that the AEAD ICV length needs to be defined by the cipher 
anyway, so my comments related to that probably don't need to be 
reiterated. However, I think the motivation behind 8-octet ICV is quite 
relevant to this discussion, so I'll include it here:

"There are low-power wireless links, such as 802.15.4, that have severe 
bandwidth and packet size constraints. The link-layer security mechanism 
for 802.15.4 is AES-CCM with an 8-octet ICV. The intent of the draft is 
to allow a minimal-strength, bandwidth-conserving authentication in TLS, 
and also to allow the link-layer crypto mechanism to be used in TLS 
instead of or in addition to at the link layer."

I think this is also related to Brian's question. What I understand he 
suggested was a generic extension that would truncate the ICV that could 
be used with AES-GCM cipher suites in addition to AES-CCM cipher suites. 
It would require slightly more work to implement, but would avoid the 
definition of special 8-octet ICV cipher suites. However if AES-CCM and 
802.15.4 are the only places where the 8-octet ICV is to be used, then 
it might be ok to leave it as it is. The motivation behind the 8-octet 
ICV cipher suites could be added to the draft though...

These are the questions that came up so far when I was reading the 
specification draft, hope they help and I'm happy to hear some comments.

Juho

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 19 Jul 2010 12:48:56 -0500

David McGrew wrote:
> GCM requires implementation of the AES forward (encrypt) operation and a
> GF(2^128) multiplier.  CCM requires only the AES forward (encrypt)
operation.
> Within the low-power radio community, there is probably an expectation
that
> the CCM ciphersuite does not need universal support; it would be adequate
if
> servers for that application environment supported it.

I do not quite understand this last comment. Would a user use a regular web
browser to connect to a 802.15.4-enabled desktop/mobile device to an
administrative interface for an 802.15.4 device over HTTPS?

I agree with Juho's comments regarding the restrictions on ClientHello
extensions and the way support for truncation is supported/requested. I do
not think it makes sense to multiply the number of AEAD cipher suite codes
by 3 just to add truncation support. And, IMO, every implementation should
support the un-truncated form, so it should be impossible for the client to
offer the truncated forms without also offering the un-truncated form.
Specifying the truncation in an extension that the server is free to ignore
would provide for that.

Regards,
Brian

---

From: David McGrew <[email-masked]>
Date: Tue, 20 Jul 2010 10:56:55 -0700

Hi Brian,

> administrative interface for an 802.15.4 device over HTTPS?

In the Zigbee SE2.0 group's recent meeting in Cincinnati, there was a  
discussion where it was concluded that it was not a priority to  
interoperate with web browsers, since many devices will not have the  
administrative interface that you're describing.

> by 3 just to add truncation support.

There are currently 17 AEAD algorithms, 8 of which are short-ICV  
versions (see http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml) 
    The four new CCM algorithms in the draft would bring those numbers  
to 21 and 12, respectively.   Adding these new algorithms are  
consistent with precedent in the AEAD registry.

Besides, "truncation" is not legal with the AEAD interface (because  
RFC5116 says that "Applications MUST NOT assume any particular  
structure or formatting of the ciphertext"), so new algorithms/numbers  
need to be defined/assigned.

> And, IMO, every implementation should

I respectfully disagree.  Users of low-power radio devices have  
already decided that it is acceptable to use 8 octets or fewer for  
authentication, and IMO TLS should accept and incorporate that  
policy.   (802.15.4 link crypto allows zero to 8 octets of  
authentication strength.)

David

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 20 Jul 2010 23:15:36 +0200

David McGrew wrote:

> I respectfully disagree.  Users of low-power radio devices have already
> decided that it is acceptable to use 8 octets or fewer for
> authentication, and IMO TLS should accept and incorporate that policy.  
> (802.15.4 link crypto allows zero to 8 octets of authentication strength.)

Different fields of technology have different needs. Could you elaborate
 on why TLS should accept and incorporate the policy for low-power radio
devices? Will low-power radio devices use TLS to communicate?

regards,
Nikos

---

From: David McGrew <[email-masked]>
Date: Wed, 21 Jul 2010 05:43:57 -0700

Hi Nikos,

On Jul 20, 2010, at 2:15 PM, Nikos Mavrogiannopoulos wrote:

>> already
>> policy.

yes, that is the plan of record.   SE2.0 is IP-based (see http://www.zigbee.org/Markets/ZigBeeSmartEnergy/Version20Documents.aspx) 
  and has voted to use TLS to protect communication above the link  
layer, though TLS ciphers and options need to be carefully considered  
in order to be suitable for the constrained environment.   This is a  
very positive thing.  Instead of inventing a completely new protocol,  
or creating a non-interoperable variant (like WTLS), the low-power  
wireless community is looking at ways of using standard TLS.

regards,

David

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 21 Jul 2010 17:16:16 +0200

David McGrew wrote:

> yes, that is the plan of record.   SE2.0 is IP-based (see
> http://www.zigbee.org/Markets/ZigBeeSmartEnergy/Version20Documents.aspx) and
> has voted to use TLS to protect communication above the link layer,
> though TLS ciphers and options need to be carefully considered in order
> to be suitable for the constrained environment.   This is a very
> positive thing.  Instead of inventing a completely new protocol, or
> creating a non-interoperable variant (like WTLS), the low-power wireless
> community is looking at ways of using standard TLS.

Indeed, this is very good news.

regards,
Nikos

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 21 Jul 2010 11:14:02 -0500

David,

Thanks for your reply. 

> RFC5116 says that "Applications MUST NOT assume any particular structure
or
> formatting of the ciphertext"), so new algorithms/numbers need to be
> defined/assigned.

I take back my objection. An extension for negotiating non-standard AEAD
parameters would be much more complicated than the truncated HMAC extension
anyway.
 
It seems like these cipher suites are really only useful for some
802.15.4(-ish) low-power devices with limited hardware, and are actually
harmful for almost all other TLS implementations. So, my understanding of
your comments is that 802.15.4(-ish) devices would implement these cipher
suites, and everybody else can ignore them (and, IMO, should ignore them).
If a 802.15.4 device wanted to communicate with the outside world using TLS,
it would have to implement other cipher suites, instead of expecting other
implementations to implement these cipher suites. Is that how the ZigBee
consortium sees things?

Regards,
Brian