Subject: [Dtls-iot] Review of draft-ietf-dice-profile-10

From: Rene Hummen <[email-masked]>
Date: Fri, 6 Mar 2015 17:45:09 +0000

Hi Hannes, Thomas, list,

sorry for the late feedback. Since you already revised parts of draft-ietf-dice-profile-09, I decided to read draft-ietf-dice-profile-10 instead ([1] from GitHub). I am especially glad to see constrained servers to be included this time around. These are my remaining comments:

1) As a general comment that applies to the whole document: Would it make sense to replace the “is envisioned” / “is not envisioned” and “are not applicable” with SHOULDs and MUSTs (NOT)? 

2) Figure 1 should also mention the client’s private key (or simply call it a public/private key-pair).

3) Section 4.2 (starting from line 689)

"In this section we look at cases where constrained devices run TLS/
   DTLS servers to secure access to application layer services running
   on top of CoAP, HTTP or other protocols.  Running server
   functionality on a constrained node is typically more demanding since
   servers have to wait for incoming requests.  Therefore, they will
   have fewer possibilities to enter sleep-cycles.  Nevertheless, there
   are legitimate reasons for deploying servers as constrained devices.”

Is there a need to educate the reader about the advantages/disadvantages of constrained servers? I suggest to replace the above text with the following:

"In this section, we assume a scenario where constrained devices run TLS/
   DTLS servers to secure access to application layer services running
   on top of CoAP, HTTP or other protocols.”

Moreover, first introducing the example and then outlining the challenge seems to be the inverted order. Why not outline the challenges first and then describe the example as one possible way to solve them?

In the example, why do you assume that reading the temperature sensor does not require authentication? The temperature information is the basis for the subsequent decision to turn on the fan, which in the example requires protection. An adversary could then still control the fan via the thermostat by injecting forged temperature information. IMHO, all communication in this scenario should be protected to give a clear message that network security is important for the entire system.  

Minor nits:

"Below we explain how these challenges have been solved
   with CoAP, as an example.”

should be

"Below we explain how these challenges __can be__ solved
   with CoAP, as an example.”

"Since RD is
      usually not a proxy clients can discover links registered with the
      RD and then access them directly."

should be

"Since RD is
      usually not a proxy__,__ clients can discover links registered with the
      RD and then access them directly.”

4) Section 5 (line 1025)

"SHA-256 is
   the recommended default PRF.”

In which document? The DTLS profile or the (D)TLS specification?

5) Section 6 (line 1033)

"Note that
   shared secrets are not passwords.”

should be

"Note that
   shared secrets are not passwords, but binary blobs of random data.”

6) Section 6.1 (line 1116)

The paragraph about the PSK identity hint is still unclear. Does this paragraph argue for or against using the hint? I guess, the strange thing about this paragraph is that it first introduces the hint as something that one actually might want to use. Then, however, recommends _against_ doing so…twice:

“If […] the server then servers SHOULD NOT send the "PSK identity
   hint" in the ServerKeyExchange message.  Servers SHOULD NOT send the
   "PSK identity hint" in the ServerKeyExchange message and clients MUST
   ignore the message.”

Plus, directly afterwards, there is a recommendation on how the SNI value can be used to help select the hint. 

Would it make sense to add a recommendation about a minimum PSK length following this text in the current specification?

“Implementations
   in compliance with this profile MAY use PSK identities up to 128
   octets in length, and arbitrary PSKs up to 64 octets in length.  The
   use of shorter PSK identities and shorter PSKs is RECOMMENDED.”

7) Section 6.3 (line 1249 and below)

"The use of the Trust Anchor
   Management Protocol (TAMP) [RFC5934] is, however, not envisioned.
   Instead IoT devices using this profile MUST use a software update
   mechanism to populate the trust anchor store.”

Is it really necessary to be so strict in how the trust anchor store is populated? Doesn’t it suffice to say:

"The Trust Anchor
   Management Protocol (TAMP) [RFC5934], however, SHOULD NOT be used.
   Instead, IoT devices using this profile SHOULD use a software update
   mechanism to populate the trust anchor store.”

I guess, this is a typo “dNSName".

8) Section 6.3.2 (line 1482)

"Since the server does not necessarily know what trust
   anchors the client has stored it includes intermediate CA certs in
   the certificate payload as well to facilitate with certification path
   construction and path validation."

should be

"Since the server does not necessarily know what trust
   anchors the client has stored and to facilitate certification path
   construction as well as path validation, it includes intermediate CA certs in
   the certificate payload.”

9) Section 13 (line 1836)

"Choosing appropriate timeout values is difficult with infrequent data
   transmissions, changing network conditions, and large variance in
   latency.”

The "infrequent data transmissions” was confusing as I had the DTLS handshake in mind and, at first, didn’t relate it to the preceding note about the round-trip time estimator. This is nit-picking, but would it make sense to simply remove "infrequent data transmissions” from this enumeration?

10) Section 17 (line 1972)

"Ultimately, the main benefit of this extension is it to
   allows client implementations to lower their […]”

Remove the “it”.

11) Section 21 (line 2089 and below)

"Ongoing discussions regarding the choice of specific
   ECC curves will also likely to impact implementations.”

Remove the “to”.

"Offer access to building blocks in addition (or as an alternative)
      to the complete functionality.  For example, a chip manufacturer
      who gives developers access to the AES crypto function can use it
      to build an efficient AES-GCM implementations.  Another example is
      to make a special instruction available that increases the speed
      of speed-up carryless multiplications.”

Why not use ECB as a basic example of a building block?

12) Appendix A (line 2673 and below)

In contrast to the remaining profile, this (obviously) is very link layer specific normative text. Why not move this to a short separate document?

BR,
René

[1] https://github.com/hannestschofenig/tschofenig-ids/commit/37d0cfa130904dcba6c2d470f286bdb98b81e41d

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 07 Mar 2015 11:08:06 +0100

Hi Rene,

thanks for your timely review.

On 03/06/2015 06:45 PM, Rene Hummen wrote:
> Hi Hannes, Thomas, list,
> 
> sorry for the late feedback. Since you already revised parts of
> draft-ietf-dice-profile-09, I decided to read
> draft-ietf-dice-profile-10 instead ([1] from GitHub). I am especially
> glad to see constrained servers to be included this time around.

It was definitely a good idea to look at the latest snapshot since I
have in the meanwhile incorporated various WGLC review comments into the
document.

> These are my remaining comments:
> 
> 1) As a general comment that applies to the whole document: Would it
> make sense to replace the “is envisioned” / “is not envisioned” and
> “are not applicable” with SHOULDs and MUSTs (NOT)?

I changed text where relevant. In some cases the words 'not applicable'
seems more appropriate. I use the word in a context where it does not
make sense to use a certain feature.

> call it a public/private key-pair).

Fixed.

> functionality on a constrained node is typically more demanding
> since servers have to wait for incoming requests.  Therefore, they
> will have fewer possibilities to enter sleep-cycles.  Nevertheless,
> there are legitimate reasons for deploying servers as constrained
> devices.”
> 
> Is there a need to educate the reader about the
> advantages/disadvantages of constrained servers? I suggest to replace
> the above text with the following:
> 
> "In this section, we assume a scenario where constrained devices run
> TLS/ DTLS servers to secure access to application layer services
> running on top of CoAP, HTTP or other protocols.”

I thought the reader may not know that.

I put your proposal in there although I am not 100% sure whether it
actually makes the text better to remove this additional background
information.

> 
> Moreover, first introducing the example and then outlining the
> challenge seems to be the inverted order. Why not outline the
> challenges first and then describe the example as one possible way to
> solve them?

Good point. I reversed the order.

> 
> In the example, why do you assume that reading the temperature sensor
> does not require authentication? The temperature information is the
> basis for the subsequent decision to turn on the fan, which in the
> example requires protection. An adversary could then still control
> the fan via the thermostat by injecting forged temperature
> information. IMHO, all communication in this scenario should be
> protected to give a clear message that network security is important
> for the entire system.

Certainly correct. I changed the example.

> 
> Minor nits:
> 
> "Below we explain how these challenges have been solved with CoAP, as
> an example.”
> 
> should be
> 
> "Below we explain how these challenges __can be__ solved with CoAP,
> as an example.”

Fixed.

> 
> 
> "Since RD is usually not a proxy clients can discover links
> registered with the RD and then access them directly."
> 
> should be
> 
> "Since RD is usually not a proxy__,__ clients can discover links
> registered with the RD and then access them directly.”
> 

Fixed.

> 
> 
> 4) Section 5 (line 1025)
> 
> "SHA-256 is the recommended default PRF.”
> 

Actually, the story is a bit more complex since the PRF is part of the
ciphersuite definition and while the TLS 1.2 spec says that new
ciphersuites should use the SHA-256 based construction it also allows a
ciphersuite to define else. I added extra text to the 'The Ciphersuite
Concept' section.

> 
> 
> 5) Section 6 (line 1033)
> 
> "Note that shared secrets are not passwords.”
> 
> should be
> 
> "Note that shared secrets are not passwords, but binary blobs of
> random data.”
> 
> 

I changed the text to make the message clearer:

"
When using pre-shared key, a critical consideration is how to assure the
randomness of these secrets.  The best practice is to ensure that any
pre-shared key contains as much randomness as possible. Deriving a
shared secret from a password, name, or other low-entropy source is not
secure. A low-entropy secret, or password, is subject to dictionary attacks.
"

> The paragraph about the PSK identity hint is still unclear. Does this
> paragraph argue for or against using the hint? I guess, the strange
> thing about this paragraph is that it first introduces the hint as
> something that one actually might want to use. Then, however,
> recommends _against_ doing so…twice:
> 
> "PSK identity hint" in the ServerKeyExchange message and clients
> MUST ignore the message.”
> 
> Plus, directly afterwards, there is a recommendation on how the SNI
> value can be used to help select the hint.

Given all this uncertainty about the PSK identity hint I removed the
paragraph.
> 
> 
> Would it make sense to add a recommendation about a minimum PSK
> length following this text in the current specification?
> 
> “Implementations in compliance with this profile MAY use PSK
> identities up to 128 octets in length, and arbitrary PSKs up to 64
> octets in length.  The use of shorter PSK identities and shorter PSKs
> is RECOMMENDED.”
> 

The problem is that we do not know what guidance to give since it
depends on a variety of factors.

> "The use of the Trust Anchor Management Protocol (TAMP) [RFC5934] is,
> however, not envisioned. Instead IoT devices using this profile MUST
> use a software update mechanism to populate the trust anchor store.”
> 
> "The Trust Anchor Management Protocol (TAMP) [RFC5934], however,
> SHOULD NOT be used. Instead, IoT devices using this profile SHOULD
> use a software update mechanism to populate the trust anchor store.”
> 

In a variety of places we say that we need a software update mechanism
and, hence, it makes little sense to be vague about the intentions.

> I guess, this is a typo “dNSName".
Nope. This is how RFC 5280 calls it.

I added a reference.

> "Since the server does not necessarily know what trust anchors the
> client has stored it includes intermediate CA certs in the
> certificate payload as well to facilitate with certification path 
> "Since the server does not necessarily know what trust anchors the
> client has stored and to facilitate certification path construction
> as well as path validation, it includes intermediate CA certs in the
> certificate payload.”
> 
Fixed.

> "Choosing appropriate timeout values is difficult with infrequent
> data transmissions, changing network conditions, and large variance
> in latency.”
> 
> The "infrequent data transmissions” was confusing as I had the DTLS
> handshake in mind and, at first, didn’t relate it to the preceding
> note about the round-trip time estimator. This is nit-picking, but
> would it make sense to simply remove "infrequent data transmissions”
> from this enumeration?
> 
> 
Fixed.

> "Ultimately, the main benefit of this extension is it to allows
> client implementations to lower their […]”
> 
> Remove the “it”.
> 
Fixed.

> "Ongoing discussions regarding the choice of specific ECC curves will
> also likely to impact implementations.”
> 
> Remove the “to”.
> 
Fixed.

> to the complete functionality.  For example, a chip manufacturer who
> gives developers access to the AES crypto function can use it to
> build an efficient AES-GCM implementations.  Another example is to
> make a special instruction available that increases the speed of
> speed-up carryless multiplications.”
> 
I didn't want to go too far with the recommendation about what should be
done in hardware but rather state high-level principles.

> In contrast to the remaining profile, this (obviously) is very link
> layer specific normative text. Why not move this to a short separate
> document?
> 

As Thomas noted the content of the appendix was actually in a separate
document. When we presented it the recommendation was made to include it
in here since the underlying message about the timeout values is
applicable also to other radio technologies.

I also believe that the text in the appendix does not disrupt
readability for others who do not care about this type of usage.

Ciao
Hannes

> 
> 
> BR, René
> 
> 
> [1]
> https://github.com/hannestschofenig/tschofenig-ids/commit/37d0cfa130904dcba6c2d470f286bdb98b81e41d
>
> 
> 
> -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication
> and Distributed Systems RWTH Aachen University, Germany tel: +49 241
> 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
> 
> 
> 
> _______________________________________________ dtls-iot mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dtls-iot
>