Subject: [core] #325: Define curve for keys and certs

From: "core issue tracker" <[email-masked]>
Date: Mon, 20 May 2013 19:40:18 -0000

#325: Define curve for keys and certs

 Sean Turner notes (msg04433d2):

 Section 9.1.3.2.1

 2) s9.1.3.2: Another TLS-related issue:

 When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please include the
 MTI curve(s).  Ever so glad that conservative curves are being used.  In
 the following, I assumed you'd want the one must and the two mays but I
 can understand if you don't.  I'd argue you do have algorithm agility with
 DTLS so you could get away with just the MUST ad not the MAYs.

 Unrelated to you, but I thought I'd let you know about: the curve
 requirements will almost certainly be removed from the mcgrew draft at my
 direction because no other D/TLS EC cipher suite specifies an MTI curve.
 There's support for conservative curves, but not enough interest in
 starting to add MTI curves instead of the application picking them.  Note
 the Zigbee folks also point to the mcgrew draft but it seems their drafts
 already include the curves so we ought to be good to go on both fronts.

 I think we need to be clear that choosing this particular cipher suite
 that it means an implementation needs to support the extensions defined in
 RFC 4492 - or if it doesn't.  I'm assuming you want it to so I'm going to
 propose some tweaking:

 OLD:

 Implementations in RawPublicKey mode MUST support the mandatory to
 implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in
 [I-D.mcgrew-tls-aes-ccm-ecc], [RFC5246], [RFC4492].

 NEW:

 Implementations in RawPublicKey mode MUST support the mandatory to
 implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in
 [I-D.mcgrew-tls-aes-ccm-ecc].   The key used MUST be ECDSA-capable; the
 curve secp256r1 MUST be supported, and the curves secp384r1 and secp521r1
 MAY be supported [RFC4492]; these curves are equivalent to the NIST P-256,
 P-384, and P-521 curves. Implementations MUST use/support (?) the
 Supported Elliptic Curves Extension and Supported Point Format extensions
 [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can
 be used as an implementation method.

 The mcgrew draft had the following instead of the last sentence so I'm
 open to whichever but I think something about the folllowing needs to be
 added:

 o The uncompressed point format MUST be supported.  Other point formats
 MAY be used. o The client SHOULD offer the elliptic_curves extension and
 the server SHOULD expect to receive it. o The client MAY offer the
 ec_point_formats extension, but the server need not expect to receive it.
 o [RFC6090] MAY be used as an implementation method.

 And then, I think we need to specify how the MTI would look: namely by
 adding the following on to the end of the paragraph.

 When the mandatory to implement DTLS cipher suite and curve and used the
 SubjectPublicKeyInfo indicates an algorithm of id-ecPublicKey with the
 namedCurves object identifier set to secp256r1 [RFC5480].   If secp384r1
 or secp521r1 are used the those object identifiers [RFC5480] are included
 instead.

 That way everybody knows what values go in the SPKI of the oob-pubkey
 draft.  Note they tried to change that field recently and I had to remind
 them not to.

 Carsten says:

 draft-mcgrew-tls-aes-ccm-ecc-06 says:

 » The curves and hash algorithms that must be supported are as follows:

 An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_128_CCM or
 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST support secp256r1 and SHA- 256. An
 implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_256_CCM or
 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST support secp384r1 and SHA- 384,
 and MAY support secp521r1 and SHA-512.

 Implementations that use other curves and hash functions SHOULD select
 them so that AES-128 is used with a curve and a hash function supporting a
 128-bit security level, and AES-256 is used with a curve and a hash
 function supporting a 192-bit or 256-bit security level. «

 Exceptions for the "SHOULD" are not given, but it seems to me that leads
 us to stick with secp256r1 for AES-128. This means the MUST, but not the
 MAYs (which would then be used with, say,
 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8).

 We also had some interoperability problems where it wasn't quite clear
 which hash function should be used for ECDHE; it is probably worth nailing
 this down here as well.

 Strawman text:

 »Implementations in RawPublicKey mode MUST support the mandatory to
 implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in
 [I-D.mcgrew-tls-aes-ccm-ecc].  The key used MUST be ECDSA-capable.  The
 curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to
 the NIST P-256 curve.  The hash function used is SHA-256. Implementations
 MUST support (?) the Supported Elliptic Curves Extension and Supported
 Point Format extensions [RFC4492]; the uncompressed point format MUST be
 supported; [RFC6090] can be used as an implementation method.«

 In comment 4, Sean Turner also says:

 4) s9.1.3.3: The 1st paragraph is about certificates but it only
 indicates the TLS cipher suite needed to be supported.  It should say
 what values go in the certificate to support the cipher suite.
 Basically, need to point to RFC 5480 and say include values X.  I'd
 suggest:

 OLD:

 Implementations in Certificate Mode MUST support the mandatory to
 implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as
 specified in [RFC5246].

 NEW (adding some more stuff + references):

 Implementations in Certificate Mode MUST support the mandatory to
 implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as
 specified in [RFC5246].  Namely, the certificate includes a
 SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey
 with namedCurves secp256r1, secp384r1, or secp521r1 [RFC5480];
 the public key format is uncompressed [RFC5480]; if included
 the key usage extension indicates digitalSignature.

 Carsten says:

 Strawman text under the previous considerations:

 »Implementations in Certificate Mode MUST support the mandatory
 to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
 as specified in [I-D.mcgrew-tls-aes-ccm-ecc].  Namely, the certificate
 includes a
 SubjectPublicKeyInfo that indicates an algorithm of
 id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the
 public key format is uncompressed [RFC5480]; the hash
 algorithm is SHA-256; if included the key usage extension
 indicates digitalSignature.«

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  [email-masked]
  [email-masked]           |     Status:  new
     Type:  other        |  Milestone:  post-IESG-1
  technical              |    Version:  coap-16
 Priority:  major        |   Keywords:
Component:  coap         |
 Severity:  Submitted    |
  WG Document            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/325>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 20 May 2013 19:53:53 -0000

Comment (by [email-masked]):

 Sean Turner also says (comment 5):

         5) s9.1.3.3: Going with the thought that there's a chain, we also
 need to
         say what algorithms can be used to sign the certificate.  I assume
 we
         want the use same algorithm for both the TLS_ECDHE_PSK and
         TLS_ECDHE_ECDSA certificate so text is needed at the end of the
 paragraph
         to indicate that:

         Certificates MUST be signed with ECDSA [RFC6090], and it MUST
         use SHA-256, SHA-384, or SHA-512 [SHS].  It is RECOMMENDED that
         the curve match the hash function's output matches the length of
         the elliptic curve order.

         On the first bit: You could lock it down to just one curve if
 that's what
         you decide to do based on comment 5.

         On the second bit: if the curve and the hash size line up then you
 can
         use RFC 6090 and we - really - want that.  Not sure if the above
 is too
         cryptic ;)

         Carsten says:

         »Certificates MUST be signed with ECDSA [RFC6090] using
         secp256r1, and it MUST use SHA-256.«

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  new
  technical              |   Milestone:  post-IESG-1
 Priority:  major        |     Version:  coap-16
Component:  coap         |  Resolution:
 Severity:  Submitted    |
  WG Document            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/325#comment:1>
core <http://tools.ietf.org/core/>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 20 May 2013 23:01:40 +0300

>         secp256r1, and it MUST use SHA-256.«

I think this is exactly the right thing to do. It is is aligned with ZigBee IP, and at least exactly what we are doing with DTLS. I would recommend text like this, as it minimises interoperability headaches and keeps implementations as simple as possible.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 21 May 2013 21:33:17 -0000

Comment (by [email-masked]):

 The ECC code we implemented is optimized for a specific curve to save
 space and improve performance on a constrained device. We currently only
 support the secp256r1 curve and SHA-256, because these are the mandatory
 ones.

 I think most implementations for constrained device will just implement
 one hash algorithm and one curve or make this chooseable at compile time.

 It would be nice to have a default value for the curve and the hash
 algorithm in use for a given cipher, so we do not have to support the TLS
 extensions for this.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/325#comment:3>
core <http://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 May 2013 08:16:47 +0200

> one hash algorithm and one curve or make this chooseable at compile time.

I read this as supporting the text proposed in the ticket.

> algorithm in use for a given cipher, so we do not have to support the TLS

Now this one is interesting.
I completely agree with the sentiment.
But how would we get those defaults in?
The DTLS protocol operates independently from any application semantics, so simply saying "DTLS for CoAP works that way" is out.
Making the curve default to secp256r1 for all of TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 would run counter to the curve-independent direction that the draft seems to be taking.
(The hash algorithm already should be the default; it seems to me not being explicit about that is just an oversight in the draft.)

How onerous are those TLS extensions?  Can you give us an example about the code and message size?

Grüße, Carsten

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 22 May 2013 09:44:56 -0000

Comment (by [email-masked]):

 We definitely need text on which hash function to use, as this is not
 clear at the moment.
 Defining a MUST for SHA-256 looks good to me.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/325#comment:4>
core <http://tools.ietf.org/core/>

---

From: Hauke Mehrtens <[email-masked]>
Date: Thu, 23 May 2013 12:33:32 +0200

> I read this as supporting the text proposed in the ticket.

Yes that's correct.

> How onerous are those TLS extensions?  Can you give us an example about the code and message size?

The code used for creating and parsing the elliptic_curves TLS extension
is not that huge to justify a new exception in the DTLS standard for
this cipher algorithm or this use case. This TLS extension extends the
Client Hello and the Server Hello by 6 bytes in case just one curve is
supported.

What about the signature_algorithms TLS extension, for me it was not
clear if I have to add this extension or not when using
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I removed it because Californium did
not liked it. ;-)

Hauke

---

From: Robert Cragie <[email-masked]>
Date: Fri, 24 May 2013 13:36:12 +0100

We used the following extensions for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 
when testing ZigBee IP:

* elliptic_curves
* ec_points_format
* signature_algorithms

Wireshark decodes it thus:

Extension: elliptic_curves
   Type: elliptic_curves (0x000a)
   Length: 4
   Elliptic Curves Length: 2
   Elliptic curves (1 curve)
     Elliptic curve: secp256r1 (0x0017)

Extension: ec_point_formats
   Type: ec_point_formats (0x000b
   Length: 2
   EC point formats Length: 1
   Elliptic curves point formats (1)
     EC point format: uncompressed (0)

Extension: signature_algorithms
   Type: signature_algorithms (0x000d)
   Length: 4
   Data (4 bytes): 00 02 04 03

The signature_algorithms field further decodes to sha256, ecdsa

Robert

On 23/05/2013 11:33, Hauke Mehrtens wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 24 May 2013 17:54:54 +0300

Robert,

Thanks. This matches what ticket #325 is saying CoAP implementations using this Cipher suite MUST support. The proposed text in #325 also says that other curve settings MAY be used. So I think we are fine with that ticket. 

I would also love to have a way to "defaut" these MUST settings in the handshake, however I agree with Carsten that might not work with all DTLS implementations (without including the extensions).  What is your opinion?

We are currently working on a new DTLS for IoT working group proposal, and we plan on having a BOF in Berlin. The mailing list for this new group will be announced very soon. One work item proposed will be profiling DTLS for IoT applications (mainly for CoAP). This could be one of the things that could be possible defined in that profile. In the mean time, we do have a Google doc with information on the activity:

https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4eDo3g8

Zach

On May 24, 2013, at 3:36 PM, Robert Cragie <[email-masked]> wrote:

> We used the following extensions for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 when testing ZigBee IP:
> 
> * elliptic_curves
> * ec_points_format
> * signature_algorithms
>

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 24 May 2013 18:13:50 -0400

> From: Zach Shelby <[email-masked]>
> Date: Fri, 24 May 2013 17:54:54 +0300
> 
> I would also love to have a way to "defaut" these MUST settings in the
> handshake, however I agree with Carsten that might not work with all
> DTLS implementations (without including the extensions).  What is your
> opinion?

Zach,

I wouldn't worry too much about trying to avoid including these
as options.  They add something like 23 bytes to one not-too-large
handshake message.  This seems like a small price to pay for
general interoperability.

The record layer seems like a better target for optimization,
given that you will likely send a lot more application messages
than handshake messages.

                                       -Richard Kelsey

[...]

> > The signature_algorithms field further decodes to sha256, ecdsa
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product.  If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.  

Thank you.

---

From: "core issue tracker" <[email-masked]>
Date: Sun, 26 May 2013 20:25:13 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [1398]:

 Fix #325

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  closed
  technical              |   Milestone:  post-IESG-1
 Priority:  major        |     Version:  coap-16
Component:  coap         |  Resolution:  fixed
 Severity:  Submitted    |
  WG Document            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: </ticket/325#comment:5>
core <http://tools.ietf.org/core/>