Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc

[Rene Struik <[e-mail]>]

Dear colleagues:

Just a short note (I will have to review the cross-referenced four or so
RFCs later):

1) to my knowledge, for relatively short frames (a few times the size of
the underlying block cipher),
the GCM mode of operation is *not* "significantly faster" than the CCM
mode of operation.

2) 802.15.4-2011 (or 802.15.4-2006 for that matter) does use the CCM*
mode of operation, where
the nonce format is incompatible with that specified in the RFC 5116 or
the mcgrew-tls-aes-ccm draft.

Given #2 above, it seems that reference to 802.15.4's use of CCM is
somewhat inopportune. Moreover, from
Don Sturek's note below, it seems that the Joe Salovey's note that
"Zigbee smart energy group has
interest in these drafts" should be taken with some grain of salt
(lukewarm interest at most, so it seems [if one
really wished to have had another cipher (on technical grounds???), then
one missed a window of opportunity
802.15.4 TG4i issued very recently and 802.15.4 TGe just went to RevCom]).

On a more detailed technical note,

a) how does one assure that nonces used by different entities never
clash if they use a
shared key for securing network traffic? (a scenario prevalent in lots
of ZigBee, RoLL, etc. scenarios).

b) I am curious as to whether the design in mcgrew-tls-aes-ccm allows
for reuse of keying material accross
layers, so as to economize on key storage and key management overhead?
(given that devices should be
assumed to have intra-device open trust domain, this seems feasible. I
am concerned the current draft may
kill off this prospect).

Based on the above, I am somewhat critical as to why this should be
pushed, certainly as a standard-track
document.

Most of these arguments I have made before, but did not see addressed.

I will provide more technical feedback later on, but prior to the
suggested December 15th deadline.

Best regards, Rene

On 01/12/2011 3:20 PM, Don Sturek wrote:
> Hi Dan,
>
> While ZigBee does specify AES-CCM* in their *commercial* specification, I
> would say the general problem is that IEEE 802.15.4 (which ZigBee uses)
> specifies AES-CCM and nearly all silicon vendors have that (not CCM*)
> available.  If we could somehow get those implementations to switch to
> GCM, I don't think we would be asking for adoption of AES-CCM.  That said,
> for the IEEE 802.15.4 devices already manufactured and in those in the
> field, either we try to align the use of TLS with what is available
> hardware wise or else bypass the AES-CCM engine in those parts and
> implement GCM in software.....
>
> Don
>
>
>
>
> On 12/1/11 12:01 PM, "Dan Harkins" <[e-mail]> wrote:
>
>> On Wed, November 30, 2011 1:34 pm, Joe Salowey wrote:
>>> The chairs would like to see if there is consensus in the TLS working
>>> group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc
>>> as working group items.  These drafts define AES-CCM cipher suites for
>>> TLS.  The Zigbee smart energy group has interest in these drafts.
>>> These
>>> drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which is
>>> a
>>> super set of AES-CCM.  The authors are requesting standards track for
>>> these ciphers.  Please note that there is an IPR declaration listed for
>>> draft-mcgrew-tls-aes-ccm-ecc available here:
>>> https://datatracker.ietf.org/ipr/1443/.  This declaration has been
>>> updated
>>> from previous declarations.   Please respond to the following by
>>> December
>>> 14, 2011 :
>>>
>>> - Do you object to taking these drafts on as working group items?
>>> (Please
>>> state the reason for you objection)
>>  No.
>>
>>> - Would you contribute time to review and provide text for the documents
>>> when needed?
>>  Yes.
>>
>>> - Do you object to standards track status for these documents?(Please
>>> state the reason for you objection)
>>  I have a mild objection. There is no point in doing CCM. GCM is faster,
>> if you're gonna implement an AEAD scheme implement GCM. If you really want
>> a 2-pass AEAD scheme you can use RFC 5297 and you get misuse-resistance
>> for free (basically the security of the mode does not collapse if you
>> reuse a nonce/counter). The only group I know pushing CCM is actually
>> pushing CCM* and, as you note, this isn't CCM*.
>>
>>  Dan.
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: [e-mail]
Skype: rstruik
cell: [phone]
USA Google voice: [phone]