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

[David McGrew <[e-mail]>]

Hi Brian,

On Jul 19, 2010, at 10:48 AM, Brian Smith wrote:

> 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.
>>
>> 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.
>>
>> 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?

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.

>
> 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.

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
> 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.

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

>
> Regards,
> Brian
>