Subject: [Dtls-iot] 2nd WGLC on draft-ietf-dice-profile, ending Feb 6th

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 3 Feb 2015 22:13:38 +0000

Hi,

Thanks to the authors for the good work.  I reviewed the latest draft and support progressing it.  I only had a few minor comments:

1)      The phrase “TLS/DTLS 1.2” is used in various forms in the draft.  However, it makes for awkward reading in some places, especially in the title of the draft.  Specifically, do we need to refer to version “1.2” in the title?

2)      There is a reference to a CoAP endpoint “URL” in section 4.1.   However, in CoAP [RFC 7252] itself the term “URI” is used in this context.  Was there a reason to change the terminology in this draft?

3)       If Appendix A information is normative (as it indicates), what was the specific reason for parking this info in an Appendix which is usually meant for optional/less-important material?  Also, has running DTLS over SMS been successfully implemented anywhere that the authors know of?

Best Regards,

Akbar

________________________________

  *   From: Zach Shelby <Zach.Shelby at arm.com<mailto:[email-masked]>>
  *   To: "dtls-iot at ietf.org<mailto:[email-masked]>" <dtls-iot at ietf.org<mailto:[email-masked]>>
  *   Date: Mon, 26 Jan 2015 05:28:12 -0800
  *   List-id: DTLS for IoT discussion list <dtls-iot.ietf.org>

________________________________
This mail kicks off a 2nd WGLC for our DTLS profile draft:

https://tools.ietf.org/html/draft-ietf-dice-profile-09

This WGLC will end of Friday, Feb 6th, 2015. Please send your reviews to this mailing list. The authors have identified some key reviewers, in addition to those that volunteered in Honolulu.

Thanks!
Zach & Dorothy

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

________________________________

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 6 Feb 2015 17:10:09 +0000

Dear authors,
dear group

I really like this document since it gives a great overview of what developers should know about (D)TLS. Most of my comments are of editorial nature:

Page 4: “with an dentical amount” --> missing ‘i’

Page 5 (4.1):

-        URL --> URI

-        “the CoAP needs to register and publish to” --> “to which CoAP needs to register and publish”

-        For the public key crypto, I am missing the private key of the client. I think the bullet list and Figure one should mention it somehow to make developers aware that using client authentication is the default in the IoT.

Page 7 (4.1.1.1): “protocol mechanism, name RADIUS or Diameter” --> “namely”

Page 10 (4.1.1.2):

-        It would be clearer to point out that the IoT device changes roles after initiating the DTLS handshake with an initial CoAP request (e.g., RD registration).

-        There are a lot of references to the RD draft; maybe we can remove the second occurrence.

-        By default, the RD is not a proxy. The model described in 4.1.1.2 comes from OMA LWM2M! Since this specification is referenced in Section 25 anyway, I would use it here as well for the use case.

Page 14 (4.2): When the multicast discovery uses CoAP without DTLS, but the other resources provide CoAPS, I would expect an absolute URI with the ‘coaps’ scheme in the CoRE Link Format. URIs with the same authority and URI path but different schemes refer to different resources. Only by “coincidence” they usually end up at the same document (HTTP(S)) or data point.

Page 15 (4.2): I am missing the RD under “Discovery and Reachability.” As stated above, the RD is usually not a proxy and client endpoints can discover links there, but then access them directly. How this is done is out of scope in this document (see ACE work).

Page 20 (6.1): “In general, servers SHOULD NOT send the PSK identity hint [..] and client MUST ignore the message.” --> I find this confusing, mostly because of “in general.” There are cases where this feature is required, but this could lead to many clients (worse implementations) that always ignore the hint. It should be more specific that this text only applies when the feature is explicitly not required. Editorial: “clients” is missing the ‘s’

Page 21 (6.2):

-        OMA LWM2M provides bootstrapping mechanisms to install new keying material. This does not require a full firmware update. I am expecting more solutions that provide such a feature.

-        “This ciphersuite make use” --> makes

Page 27 (8): I still believe it is much more helpful to have the list of applicable error messages in the document instead of those not applicable.

Page 31 (13): “and twice the value” --> knowing CoAP I assume the value is doubled each time, but the word “twice” (or short sentence) does not clearly say that in my opinion.

Page 37 (21): “to an the” --> only “the”

Page 27 (22):

-        “and a 233 bit ECC keys” --> “a 233-bit key” (or plural in all cases)

-        “The use 80-bit” --> “The 80-bit encryption used” ?

Best regards
Matthias

From: dtls-iot [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Tuesday, 3 February 2015 23:14
To: [email-masked]
Subject: [Dtls-iot] 2nd WGLC on draft-ietf-dice-profile, ending Feb 6th

Hi,

Best Regards,

Akbar

Thanks!
Zach & Dorothy