Subject: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (with DISCUSS and COMMENT)

From: "Sean Turner" <[email-masked]>
Date: Wed, 15 May 2013 23:29:41 -0700

Sean Turner has entered the following ballot position for
draft-ietf-core-coap-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for a clear draft.  Makes things so much easier to review.  Just
want to discuss a couple of things before moving to yes (hopefully).

0) s9.1.3.2: Before I get in to the nitty-gritty of the specific concerns
I have with DTLS use of Raw Public Keys, I have to ask whether use of the
DTLS client_certificate_url extension was considered?  If raw public keys
is just about size then that'd work wouldn't it.  If you're about dumping
processing of paths, then that's another thing.

1) s9.1.3.2.1: What's really hung me up on this draft is the raw public
key option.  Primarily, the TLS draft is not quite done yet; I'm still in
discussions with the authors.  Two issues that affect your draft:

a)  <soap box> By draft-ietf-tls-oob-pubkey taking a pass on specifying
all of the ways an identity can be bound to a public key, it leaves it up
to the application to specify that mechanism.  This binding is important
because you can't get peer authentication without it; I'm really worried
that if this mode gets widely deployed people will say they have "DTLS
security" but few (if any) are actually do the work necessary to bind the
identity to the key.  </soap box>  So, you specify that binding in the
provisioning section (good ;) but I want to make sure that it's clear
who's doing what to whom:

i) s9.1.3.2.1: For machines it's perfect appropriate to generate the key
and install it because we doubt it'll be able to do that well enough
right (i.e., crummy entropy sources)?  I want to make it clear that
that's been done by the manufacturer.

 In this mode the device has an asymmetric key pair but without an
 X.509 certificate (called a raw public key).
 
to:

 In this mode the device has an asymmetric key pair but without an
 X.509 certificate (called a raw public key); the asymmetric key
 paid is generated by the manufacturer and installed on the device.

ii) s9.1.3.2.1: This draft does that binding using Stephen's naming thing
with hashes, but I want to make sure that it's clear who is identifier,
it now says:

  An identifier is calculated
  from the public key as described in Section 2 of [RFC6920]. 

Is it the 

  An identifier is calculated by the endpoint from
  from the public key as described in Section 2 of [RFC6920]. 

b) draft-ietf-tls-oob-pubkey is likely to take a pass on specifying a
mechanism for revoking the public key and identity binding.  Note that
ocsp-/multi-ocsp staplingwon't work because there's no way to request
information about a certificate that you don't have information about.  
I'm not trying to gold plate the security mechanism here but I think we
need some words on how revocation for this mode will be handled. 
However, I suspect you'll want to use the ACLs....there's a mechanism for
including ACLs during provisioning but is there a way to update them
later?  What happens if a new node gets installed or removed?  Is there a
requirement for ACLs to be supported; the text has a SHOULD but that
seems to be about ACL provisioning support not ACL support.

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.

3) s9:  I know we're all about be liberal in what you accept, but in this
context that might be challengeing; this bit:

 ... all modes of DTLS may not be
 applicable.  Some DTLS cipher suites can add significant
 implementation complexity as well as some initial
 handshake overhead
 needed when setting up the security association.

Made me wonder whether you considered which other DTLS extensions might
be useful in addition to the EC ones and SNI as well as what extensions
should be profiled out?  For example, max_fragment_length looks pretty
useful in this context as well as certificate_url.  But does heartbeat
make any sense?

4) s8: I think you need to make it pretty darn clear in s8 that
multi-cast is an unsecured "mode" as specified in this document.  It's
kind of buried in s9.

5) s9.1.2: (worried about a DoS attack) Do you mean that responses to
secured-CoAP messages returned unsecured are silently discarded/ignored
or rejected and then that kicks off an error code response?

6) s9.1.3.1: Did you consider whether there should be an application
profile for the psk_identity_hint (see Section 5 [RFC4279]) - i.e., is
there a standard format for CoAP that should be defined?

7) s9.1.3.3: When you say "the Certificate must be validated" I'm just
checking that you're think there's going to be a certificate chain?  If
there's no chain the validation rules in 5280 don't apply.

8) s9: If you're going to allow more than two entities to share the
preshared keys I think it's worth pointing out you really can't get peer
authentication with either CoAP or DTLS.  The description in s9 and
elsewhere seems to imply that more than one peer might share the same
key.

9) Either in s9 or s11 we need to say something about devices with bad
entropy sources not bothering to make keys because they won't be of any
use.   If they've got bad entropy sources the manufacturer or whoever
should be making the keys.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

0) s1.2: Is the "CoAP-to-CoAP proxy" definition missing?  s5.7 refers to
s1.2 for the definition but that term is not in s1.2.

1) s7.1: I think this is munged:

  A server is discovered by a client by the client knowing or

2) s9: In the NoSec option is worth also pointing to the link layer
security (IEEE 802.15.4)?

3) s9.1: Because there's no s9.2 (I assume that might have been an
IPsec-secured CoAP section at one point) you can drop the header.

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.

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 fist 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 ;)

6) s9.1.3.3: Maybe a typo MUST instead of must:

 If there is no
 SubjectAltName in the certificate, then the Authoritative Name must
 match the CN found in the certificate using the matching rules
 defined in [RFC2818] with the exception that certificates with
 wildcards are not allowed.

7) s9.1.3.3: r/further work./further study.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 May 2013 08:29:10 +0200

Sean,

thank you for the juicy review -- this was well worth the wait; we are still busy processing the finer points and will have a response soon.

> with DTLS so you could get away with just the MUST ad not the MAYs.

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

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 17 May 2013 11:52:07 +0300

> Exceptions for the "SHOULD" are not given, but it seems to me that leads us to stick with secp256r1 for AES-128.

This is in practice what we're all using commercially right now anyways.

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: Carsten Bormann <[email-masked]>
Date: Tue, 21 May 2013 02:36:01 +0200

> thank you for the juicy review -- this was well worth the wait; we are still busy processing the finer points and will have a response soon.

Finally, here is that response.

Tickets #323 to #326 are in response to this; there is also another security-related ticket (#322); we will probably process these in the course of this week.
This should lead to a -17 by early next week.

Grüße, Carsten

The motivation for RPK usage is mainly about avoiding having to
include certificate processing in constrained nodes, but also about a
rough fit between classic certificates and some deployment models.
(We do have a certificate mode though, and *that* might benefit from
client_certificate_url, but see below.)

I seem to remember we discussed client_certificate_url as an
optimization strategy briefly at least on the hallways (I cannot find
a record on the mailing list).  Adding state logic to retrieve the
certs from the URLs didn't seem attractive to the implementers
involved.  So we haven't spent the energy to discuss whether section
11.3 of RFC 6066 affects our area of application much, and how we
would set the parameters mentioned there.  Clearly, adding SHA-1 just
for this (we are clean SHA-256 otherwise) is another turn-off.

        to:

Well, it is probably more appropriate to suggest this than to state it
as a fact.  (It is certainly not a requirement, as there are other
ways to do provisioning.)  See also the new section 11.6.

Strawman text:

...; e.g., the asymmetric key pair is generated by the manufacturer and
installed on the device.

-> #324

        Is it the 

Indeed. [1381]

Indeed, in practice RPK requires you to do the same thing as PSK: You
need to keep an ACL list on both the DTLS Client and Server. The only
way to "revoke" an RPK is to remove it from your ACL. This is exactly
what commercial systems are doing.
Clarified somewhat in [1382].

        OLD:

         Implementations in

        NEW:

         Implementations in

-> #325

No, we didn't spend energy vetting the set of extensions.
There is considerable interest in the CoRE community to do more work
about DTLS in constrained environments.  I would expect more documents
to come out of that, which will clarify the appropriate options.

Now also discussed in 8.1. [1379]

Other IESG members have already commented that we use the term
"Rejected" in a surprising way.  Here, a piggy-backed response from an
unexpected endpoint would simply be discarded (or, if it is using a
Confirmable message, elicit a Reset).

I don't think the WG has discussed if there can be a single RFC 4279
application profile for all DTLS PSK usage in CoAP or whether these
would be specific to particular commissioning models.

-> #326

9.1.3.3 is about the Certificate Mode, in which we indeed do expect to
have a certificate chain.

The implication seemed kind of obvious, but it sure can't hurt to
point it out explicitly.  [1376]

Good point. So far we talk about entropy only in 9.1.3.1.  There are
other considerations about constrained nodes (e.g., susceptibility to
timing attacks) that may be worth mentioning.  I'll propose adding a
section 11.6 with some of these considerations.

-> #323

Added. [1377]

(It parses for me.)
I put the "knowing or" into a parenthesis to clarify. [1375]

Added (with an exhortation about key management). [1378]

Renumbering a spec at this stage of widespread discussion is expensive
-- all comments that refer to a section lose their footing.  I'd try
to avoid this now (and maybe do it at the RFC editor stage).

        OLD:

Included in:
-> #325

Included in:
-> #325

        If there is no

[1383]

[1374]

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 May 2013 15:08:17 -0400

> thank you for the juicy review -- this was well worth the wait; we are still busy processing the finer points and will have a response soon.

Wish I could have been quicker.

> This means the MUST, but not the MAYs (which would then be used with, say, TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8).

I'd be happy with you just picking the one MUST: secp256r1 for AES-128.

spt