Paul Hoffman | 1 Dec 2011 01:23

Re: Consensus for adoption of draft-wouters-tls-oob-pubkey-02

On Nov 30, 2011, at 1:43 PM, Joe Salowey wrote:

> The chairs would like to confirm the consensus of the TLS working group to adopt
draft-wouters-tls-oob-pubkey-02 as a working group item.  There was strong interest in this document at
previous IETF meetings and the controversial options dealing with only providing public key hashes have
been removed.   Please respond to the following questions by December 14, 2011:
> 
> - Do you object to taking this draft on as working group item? (Please state the reason for you objection)

No objection; in fact, support.

> - Would you contribute time to review and provide text for the document when needed?

Yes, definitely.

--Paul Hoffman
Martin Rex | 1 Dec 2011 01:29
Picon
Favicon

Re: Consensus for adoption of draft-wouters-tls-oob-pubkey-02

Joe Salowey wrote:
> 
> The chairs would like to confirm the consensus of the TLS working group
> to adopt draft-wouters-tls-oob-pubkey-02 as a working group item.
> 
> - Do you object to taking this draft on as working group item?
>   (Please state the reason for you objection)

No objection.

> 
> - Would you contribute time to review

yes (some).

>
> and provide text for the document when needed?

a little.

-Martin
Peter Gutmann | 1 Dec 2011 04:52
Picon
Picon
Picon
Favicon

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

Joe Salowey <jsalowey <at> cisco.com> writes:

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

Oh, and while that's being done can I add a third one, draft-gutmann-tls-
eccsuites-02.txt, available at
http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-02?  This has already
been discussed on the list in the past, there are interoperable
implementations, it just needs to be moved to the RFC stage to get the
necessary code points allocated.

Peter.
zhou.sujing | 1 Dec 2011 08:16
Picon

答复: consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc


tls-bounces <at> ietf.org 写于 2011-12-01 05:34:59:

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

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

No.

-Sujing

>
>
> Cheers,
>
> Joe
> _______________________________________________
> TLS mailing list
> TLS <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
zhou.sujing | 1 Dec 2011 08:28
Picon

答复: Consensus for adoption of draft-wouters-tls-oob-pubkey-02



> The chairs would like to confirm the consensus of the TLS working
> group to adopt draft-wouters-tls-oob-pubkey-02 as a working group
> item.  There was strong interest in this document at previous IETF
> meetings and the controversial options dealing with only providing
> public key hashes have been removed.   Please respond to the
> following questions by December 14, 2011:
>
> - Do you object to taking this draft on as working group item?
> (Please state the reason for you objection)

No.
>
> - Would you contribute time to review and provide text for the
> document when needed?

Yes.  

And currently there are two  unclear descriptions to me:
 1. Will client also send rawpublic key to server?
   although the aim of OOB is to reduce the size of transported server certificate, client will have to be affected according to this solution unless otherwise defined.
   
 2. What will client do on receiving  certificaterequest?
    Comparing received rawpublic key and stored public key bit by bit? But nomatterhow, definitly not " identical to the TLS specification" as described in this document.


Regards.


-Sujing

>
> Thanks,
>
> Joe
> _______________________________________________
> TLS mailing list
> TLS <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Nikos Mavrogiannopoulos | 1 Dec 2011 09:20

Re: Consensus for adoption of draft-wouters-tls-oob-pubkey-02

On 11/30/2011 10:43 PM, Joe Salowey wrote:
> The chairs would like to confirm the consensus of the TLS working group to adopt
draft-wouters-tls-oob-pubkey-02 as a working group item.  There was strong interest in this document at
previous IETF meetings and the controversial options dealing with only providing public key hashes have
been removed.   Please respond to the following questions by December 14, 2011:
> - Do you object to taking this draft on as working group item? (Please state the reason for you objection)

no.

> - Would you contribute time to review and provide text for the document when needed?

yes.

regards,
Nikos
Nikos Mavrogiannopoulos | 1 Dec 2011 09:32

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

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
Dan Harkins | 1 Dec 2011 21:01

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


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.
Don Sturek | 1 Dec 2011 21:20
Picon
Favicon

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

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" <dharkins <at> lounge.org> 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
>TLS <at> ietf.org
>https://www.ietf.org/mailman/listinfo/tls
Rene Struik | 1 Dec 2011 21:58
Picon

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

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" <dharkins <at> lounge.org> 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
>> TLS <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--

-- 
email: rstruik.ext <at> gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

Gmane