Subject: [TLS] draft-mcgrew-tls-aes-ccm-ecc

From: Sean Turner <[email-masked]>
Date: Tue, 23 Apr 2013 13:16:38 -0400

Hi,

I've been asked to shepherd this document.  It's a normative reference 
for the core COAP WG specification.

My question is whether this draft should include an MTI curve or whether 
that should be left up to the application.  I ask because no other EC 
TLS cipher suite picks a curve.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Apr 2013 10:53:34 -0700

On Apr 23, 2013, at 10:16 AM, Sean Turner <[email-masked]> wrote:

> My question is whether this draft should include an MTI curve or whether that should be left up to the application.  I ask because no other EC TLS cipher suite picks a curve.

The current draft (draft-mcgrew-tls-aes-ccm-ecc-06) does include a mandatory-to-implement curve for interoperability, but allows other curves as well. That seems useful for interoperability; otherwise, the application that is specifying the ciphersuites must specify their own mandatory-to-implement curve. The current draft allows them to just point at the spec without having to add more text in order to get interoperability.

Either way leads to the same result, but putting a conservative mandatory-to-implement curve in the ciphersuite document makes things a bit easier for people writing profiles.

--Paul Hoffman

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 23 Apr 2013 17:58:43 +0000

Hi Sean,

On 4/23/13 1:53 PM, "Paul Hoffman" <[email-masked]> wrote:

>> My question is whether this draft should include an MTI curve or
>>whether that should be left up to the application.  I ask because no
>>other EC TLS cipher suite picks a curve.
>
>The current draft (draft-mcgrew-tls-aes-ccm-ecc-06) does include a
>mandatory-to-implement curve for interoperability, but allows other
>curves as well. That seems useful for interoperability; otherwise, the
>application that is specifying the ciphersuites must specify their own
>mandatory-to-implement curve. The current draft allows them to just point
>at the spec without having to add more text in order to get
>interoperability.
>
>Either way leads to the same result, but putting a conservative
>mandatory-to-implement curve in the ciphersuite document makes things a
>bit easier for people writing profiles.

I agree with Paul's points.  ECC has a lot of options, and having a MTI
subset promotes interoperability.

David, speaking as an WG participant and not the doc author

>
>--Paul Hoffman
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Apr 2013 17:05:07 -0400

Sean:

I do not think this out to include the MTI curve.  I would greatly prefer that COAP make use of one of the curves that is already specified.  I think a strong reason is needed to specify more curves; the specification of too many will reduce interoperability.

Russ

On Apr 23, 2013, at 1:16 PM, Sean Turner wrote:

> Hi,
> 
> I've been asked to shepherd this document.  It's a normative reference for the core COAP WG specification.
>

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 23 Apr 2013 14:32:31 -0700

Hi David,

I have two questions about the _CCM_8 cipher suites in the -06 draft.

1. I think the Security Considerations section should discuss when it
is safe to use the _CCM_8 cipher suites, or state that it is always
safe to use them.

2. NIST SP 800-38C Appendix B.2 seems to say it is always safe to use
a MAC length (Tlen) of 64 with CCM. In contrast, NIST SP 800-38D
Appendix C seems to say that for GCM, 64-bit authentication tags are
only appropriate under some constraints. Does this mean there are some
fundamental differences between CCM and GCM regarding the use of a
64-bit MAC/tag?

Thanks,
Wan-Teh

---

From: Adam Langley <[email-masked]>
Date: Tue, 23 Apr 2013 17:40:56 -0400

On Tue, Apr 23, 2013 at 5:32 PM, Wan-Teh Chang <[email-masked]> wrote:
> Does this mean there are some

I believe that short GCM tags have the weaknesses described in [1],
section 4 and 5.

CCM uses CBC-MAC and so I believe that the forgery probability goes as
one would expect of an n-bit tag.

[1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf

Cheers

AGL

---

From: Paul Duffy <[email-masked]>
Date: Wed, 24 Apr 2013 01:23:44 -0400

Hi Sean

I agree with the comments offered by Paul, Russ, and David.

FYI, whatever normative dependency exists between CoAP and this draft, 
several efforts of the Zigbee Alliance also have normative references to 
this draft (Zigbee IP and Smart Energy Profile 2). The draft was 
triggered by SEP2's extensive vetting for an ECC standard for LLNs.  The 
Zigbee products are undergoing certification and initial deployments are 
expected to begin this year.

Cheers

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Apr 2013 18:07:24 +0100

Hi Sean,

I too agree with the comments provided by Paul Hoffman, Russ, David and 
Paul Duffy and also feel the conservative MTI curves specified in the 
draft promote interoperability.

Robert

On 24/04/2013 06:23, Paul Duffy wrote:
> several efforts of the Zigbee Alliance also have normative references 
> to this draft (Zigbee IP and Smart Energy Profile 2). The draft was 
> triggered by SEP2's extensive vetting for an ECC standard for LLNs.  
> The Zigbee products are undergoing certification and initial 
> deployments are expected to begin this year.
>
> Cheers
>
>
>
>> I do not think this out to include the MTI curve.  I would greatly 
>> prefer that COAP make use of one of the curves that is already 
>> specified.  I think a strong reason is needed to specify more curves; 
>> the specification of too many will reduce interoperability.
>>
>> Russ
>>
>>
>>> I've been asked to shepherd this document.  It's a normative 
>>> reference for the core COAP WG specification.
>>>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 30 Apr 2013 16:12:00 +0300

On Tue, Apr 23, 2013 at 8:16 PM, Sean Turner <[email-masked]> wrote:
> that should be left up to the application.  I ask because no other EC TLS
> cipher suite picks a curve.

Having a standard curve one can rely on promotes interoperability, but
that cannot be easily done on a single ciphersuite. That is because
this mandatory curve applies to the certificate as well, and it is
often not feasible to require multiple certificates for each
ciphersuite (assuming another ciphersuite will define a different set
of mandatory curves).

For that it could be more useful if the suggested curves were
published as an update to RFC4492.

As such I am not in favor for this specific ciphersuite to select a
mandatory curve, but rather to define a smaller set of mandatory
curves that apply for all TLS ciphersuites.

regards,
Nikos