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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 13:58:42 +0100

Hi Akbar,

thanks for your review comments.

On 02/03/2015 11:13 PM, Rahman, Akbar wrote:
> 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?

I removed the version number from the title.

Whenever the text was applicable to both versions (DTLS and TLS) I
indicated it with TLS/DTLS. If the text was only applicable to TLS or
DTLS I used TLS and DTLS, respectively.

Hence, I prefer to keep the TLS/DTLS indication to make the difference
clear in the text.
> 
>  
> 
> 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?
> 

I changed the sentence and referred to the URI rather to a URL

> 
> 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?
I put the text into the appendix since it appears to be relevant only to
smaller audience (compared to the rest of the document). Note that it is
not uncommon to put normative text into the appendix.

Part of it was implemented (namely the PSK version) but not the public
key-based variants. Note that the generic recommendations derived from
the SMS experience as a transport (particularly the timeout aspects) are
included in the main part of the document.

Ciao
Hannes

> 
>  
> 
>  
> 
> 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
> 
> ------------------------------------------------------------------------
> 
>  
> 
> 
> 
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 15:20:17 +0100

Hi Matthias,

thanks for the review. Remarks inline:

On 02/06/2015 06:10 PM, Kovatsch Matthias wrote:> 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’
>

Fixed.

> Page 5 (4.1):
> -        URL àURI
Fixed.

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

Changed to:

"
Before a client can initiate the TLS/DTLS handshake it needs to know the
IP address of that server and what credentials to use. Application layer
protocols, such as CoAP, which is conveyed on top of DTLS, may be
configured with URIs of the endpoints to which CoAP needs to register
and publish data.
"

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

Good point.

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

Fixed.

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

I looked at the message exchange again and it does not look too bad.
Ultimately, the document is about TLS/DTLS rather than a detailed
description about CoAP.

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

Removed some of them.

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

Good point. I added the reference and adjusted the sentences.

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

Good that you raised this point.

What would I put in these coaps URIs? The problem is that I have to
compare the content of the certificate with the URI.

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

Added.

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

I removed the "in general".

The reason we put that statement in there is that we couldn't figure out
how to use it in an IoT context.

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

I agree.

>
> -        “This ciphersuite make use” àmakes

fixed.

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

The problem is that those might get out of date fairly quickly when new
error messages are added with extensions.

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

Ack

>
> Page 37 (21): “to an the” àonly “the”
>
>
Ack.

>
> Page 27 (22):
>
> -        “and a 233 bit ECC keys” à“a 233-bit key” (or plural in all
cases)
Ack.

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

Changed it to
"
The authors of [ENISA-Report2013] add that a 80-bit symmetric key is
sufficient for legacy applications for the coming years, but a 128-bit
symmetric key is the minimum requirement for new systems being deployed.
The authors further note that one needs to also take into account the
length of time data needs to be kept secure for. The use of 80-bit
symmetric keys for transactional data may be acceptable for the near
future while one has to insist on 128-bit symmetric keys for long lived
data.
"

Ciao
Hannes

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