Subject: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01

From: Thomas Herbst <[email-masked]>
Date: Mon, 1 Aug 2011 14:13:17 -0700

Not sure where this fits into the wg chair's extensions triaging, but was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week.

In Zigbee we'd specified ccm as most of the 802.15.4 chips have hardware support.

tom

---

From: Robert Cragie <[email-masked]>
Date: Fri, 05 Aug 2011 15:45:16 +0100

I would like to poke the coals on this one again too.

There was a presentation at IETF80 regarding two drafts originating from 
David McGrew (draft-mcgrew-tls-aes-ccm-01 and 
draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC 
there were no significant objections to this moving forward. However 
there was no particular support from the WG chairs for doing this 
through the WG. In the meantime, a number of vendors have been using 
these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and 
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms 
successfully.

Therefore I would like to get an clear view as to the way to move this 
forward - either through the WG or as individual submissions.

Thanks

Robert

On 01/08/2011 10:13 PM, Thomas Herbst wrote:
> Not sure where this fits into the wg chair's extensions triaging, but 
> was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Joe Salowey <[email-masked]>
Date: Fri, 5 Aug 2011 08:47:28 -0700

Where we left this was there was some, but not overwhelming support to bring it into the working group.  It was left to the authors on which path to take, through the working group process or as an individual submission.   If you go through the working group it is more likely there will be changes than if you go the individual submission route.   Matthew also raised the question of standards track vs information for ECC cipher suites.   For ECC, I still believe that informational will be the most expedient.   

Joe
On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote:

> There was a presentation at IETF80 regarding two drafts originating from David McGrew (draft-mcgrew-tls-aes-ccm-01 and draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC there were no significant objections to this moving forward. However there was no particular support from the WG chairs for doing this through the WG. In the meantime, a number of vendors have been using these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms successfully.
> 
> Therefore I would like to get an clear view as to the way to move this forward - either through the WG or as individual submissions.
> 
> Thanks
> 
> Robert
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 05 Aug 2011 12:36:22 -0400

Dear colleagues:

It would help if one could elaborate somewhat more on some of the
implicit design decisions underlying those internet drafts.

Example:
The nonce construction with the CCM mode in the drafts seems to be
incompatible with that suggested with 802.15.4-2006 (as mentioned in the
introduction and, presumably, to be used with ZigBee SE2.0).  If so,
this suggests one has to segregate key management for the MAC (if using
802.15.4) and for higher layers, including the management of counters
used with the CCM mode of operation.

Best regards, Rene

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Don Sturek <[email-masked]>
Date: Fri, 05 Aug 2011 09:42:42 -0700

Hi Rene,

Can you elaborate on the issue around this topic "If so,
this suggests one has to segregate key management for the MAC (if using
802.15.4) and for higher layers, including the management of counters
used with the CCM mode of operation."?

On the surface, segregating key management for the MAC from the higher
layers seems like the *right* thing to do!

Don

On 8/5/11 9:36 AM, "Rene Struik" <[email-masked]> wrote:

>> Where we left this was there was some, but not overwhelming support to
>>bring it into the working group.  It was left to the authors on which
>>path to take, through the working group process or as an individual
>>submission.   If you go through the working group it is more likely
>>there will be changes than if you go the individual submission route.
>>Matthew also raised the question of standards track vs information for
>>ECC cipher suites.   For ECC, I still believe that informational will be
>>the most expedient.
>>
>> Joe
>>> There was a presentation at IETF80 regarding two drafts originating
>>>from David McGrew (draft-mcgrew-tls-aes-ccm-01 and

---

From: Robert Cragie <[email-masked]>
Date: Fri, 05 Aug 2011 18:59:34 +0100

Hi Rene,

It's not an issue. The CCM mode used in the drafts is not the same as 
that in 802.15.4 and that was quite deliberate; there was never an 
intent to make this specific to 802.15.4, more that it was recognized 
that 802.15.4 devices use CCM mode therefore this can be leveraged 
efficiently for TLS implementations. Key management for the TLS use is 
distinct from the key management of the MAC security material - I can't 
see why you would ever want to commonize frame counters across layers.

Robert

---

From: Rene Struik <[email-masked]>
Date: Fri, 05 Aug 2011 16:42:20 -0400

Hi Robert:

I do appreciate that one should not just tailor towards the 802.15.4 MAC
and make this more agnostic w.r.t. lower layers. Nevertheless, I was
just curious whether the design choices have the *potential* to work
together with, e.g., 802.15.4 and realize an implementation that
minimizes the state one has to keep on a device. This minimum would be
one key and one counter per incoming device, irrespective of layer. In
fact, the "one counter per incoming device" could be reduced to "one
loosely synchronized notion of time" instead, thereby reducing state to
one key and one loosely synchronized clock. It is not clear to me
whether, with the I-Ds, one can get close to this.

Best regards, Rene

On 05/08/2011 1:59 PM, Robert Cragie wrote:
> distinct from the key management of the MAC security material - I
> can't see why you would ever want to commonize frame counters across
> layers.
>
> Robert
>
>>> Where we left this was there was some, but not overwhelming support
>>> to bring it into the working group.  It was left to the authors on
>>> which path to take, through the working group process or as an
>>> individual submission.   If you go through the working group it is
>>> more likely there will be changes than if you go the individual
>>> submission route.   Matthew also raised the question of standards
>>> track vs information for ECC cipher suites.   For ECC, I still
>>> believe that informational will be the most expedient.
>>>
>>> Joe
>>>> there were no significant objections to this moving forward.
>>>> However there was no particular support from the WG chairs for
>>>> doing this through the WG. In the meantime, a number of vendors
>>>> have been using these drafts and testing the
>>>> TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
>>>> in both PANA/EAP-TLS and TLS forms successfully.
>>>>
>>>> Therefore I would like to get an clear view as to the way to move
>>>> this forward - either through the WG or as individual submissions.
>>>>
>>>> Thanks
>>>>
>>>> Robert
>>>>
>>>>> Not sure where this fits into the wg chair's extensions triaging,
>>>>> but was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last
>>>>> week.
>>>>>