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

Robert Cragie <robert.cragie@gridmerge.com> Fri, 05 August 2011 17:58 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577311E8070 for <tls@ietfa.amsl.com>; Fri, 5 Aug 2011 10:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyPra89f8RFm for <tls@ietfa.amsl.com>; Fri, 5 Aug 2011 10:58:06 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id C29E921F886C for <tls@ietf.org>; Fri, 5 Aug 2011 10:58:05 -0700 (PDT)
Received: from client-82-26-175-170.pete.adsl.virginmedia.com ([82.26.175.170] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QpOex-00013E-BX; Fri, 05 Aug 2011 18:58:11 +0100
Message-ID: <4E3C2F86.1090303@gridmerge.com>
Date: Fri, 05 Aug 2011 18:59:34 +0100
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Rene Struik <rstruik.ext@gmail.com>
References: <CA5C64FD.F40A%therbst@silverspringnet.com> <4E3C01FC.2060408@gridmerge.com> <E05B5D85-F99C-4B14-BE0D-BB02F01F9A7E@cisco.com> <4E3C1C06.1040801@gmail.com>
In-Reply-To: <4E3C1C06.1040801@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms080204070406070803000808"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: tls@ietf.org
Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2011 17:58:06 -0000

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

On 05/08/2011 5:36 PM, Rene Struik wrote:
> 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
>
> On 05/08/2011 11:47 AM, Joe Salowey 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
>> On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote:
>>
>>> 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.
>>>>
>>>> In Zigbee we'd specified ccm as most of the 802.15.4 chips have hardware support.
>>>>
>>>> tom
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>>
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>