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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 01 Dec 2011 09:32:16 +0100

On 11/30/2011 10: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?

No.

> - Do you object to standards track status for these documents?(Please state the reason for you objection)

I object unless a clarification is given to the question below.
Given that these documents define optional ciphersuites for a small
target, what is the difference of having an informational or standards
track status?

regards,
Nikos

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 1 Dec 2011 12:01:27 -0800 (PST)

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

  No.

> - Would you contribute time to review and provide text for the documents

  Yes.

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

---

From: Don Sturek <[email-masked]>
Date: Thu, 01 Dec 2011 12:20:38 -0800

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" <[email-masked]> wrote:

>> - Do you object to taking these drafts on as working group items?
>>(Please
>> state the reason for you objection)
>
>  No.
>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Rene Struik <[email-masked]>
Date: Thu, 01 Dec 2011 15:58:42 -0500

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

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

---

From: Robert Cragie <[email-masked]>
Date: Tue, 06 Dec 2011 18:29:50 +0000

Hi Rene,

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

Robert

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

> Moreover, from
<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>
> 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>
> am concerned the current draft may
<RCC>I think the question is more whether it would preclude it and the 
answer is IMHO no.</RCC>
> pushed, certainly as a standard-track
<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>
>> On 12/1/11 12:01 PM, "Dan Harkins"<[email-masked]>  wrote:
>>

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Dec 2011 20:14:55 +0100 (MET)

Joe Salowey wrote:
> as working group items.
> Please respond to the following by December 14, 2011 :

Sorry, I'm late.

> - Do you object to taking these drafts on as working group items?

While I do not object, I do not see a need for these to become WG items.
I believe they could remain individual submissions and still be
discussed in the WG.  But I want to leave any decisions to those who intend
to contribute to that work.

> - Would you contribute time to review and provide text for the

Unlikely.

> 
> - Do you object to standards track status for these documents?

Yes, I do.
I am not aware of a rationale why they *should* go on the standards track.
We are not actually short of TLS ciphersuite proposals.

Standards track should be reserved to documents that are considered
generally useful and where it is intended to recommend implementing
them and where the WG has the commitment to drive the document
through the whole standardization process (i.e. beyond PS).

With respect to the "2 maturity levels" discussion on the ietf mailing
list, the reason why there are so many RFCs at proposed and only very
few progressing further is a lack of both, commitment by the WG to
work the document further and lack of general usefulness of a non-marginal
part of those documents.

-Martin

---

From: Robert Cragie <[email-masked]>
Date: Mon, 19 Dec 2011 19:57:13 +0000

> to contribute to that work.
We have been going around the houses on this somewhat. I have no 
particular preference either but would like to take the quickest route 
and was under the assumption this would be the quickest route.
> through the whole standardization process (i.e. beyond PS).
Code using these documents is currently being implemented in ZigBee IP 
and SEP 2.0 platforms. So from that point of view they are unlikely to 
remain esoteric. It is for the very reason you state that I would prefer 
them to be standards track or at least reflect the status of RFC 5288 
and RFC 5289 on which they are based.

Robert