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

[Robert Cragie <[e-mail]>]

Hi Rene,

Comments inline, bracketed by <RCC></RCC>

Robert

On 01/12/2011 8:58 PM, Rene Struik wrote:
> 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.
<RCC>Not necessarily - it depends on the implementation of AES-CCM or 
AES-CCM*.</RCC>

> 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]).
<RCC>I am not sure what your point is. The fact is we are using these 
drafts in efficient ZigBee IP implementations based on current 
technology.</RCC>
>
> 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).
<RCC>I would say this is somewhat out of scope for a TLS specification 
but the situation exists for GCM as well and is covered in RFC 5116 for 
both GCM and CCM</RCC>
>
> 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).
<RCC>I think the question is more whether it would preclude it and the 
answer is IMHO no.</RCC>
>
> Based on the above, I am somewhat critical as to why this should be
> pushed, certainly as a standard-track
> document.
<RCC>The aim was to align with the two GCM documents, i.e. align 
draft-mcgrew-tls-aes-ccm with RFC 5288 (standards track) and 
draft-mcgrew-tls-aes-ccm-ecc with RFC 5289 (informational). This seems 
reasonable as they are equivalent</RCC>
>
> 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
>