Subject: Re: [Dtls-iot] I-D Action: draft-ietf-dice-profile-00.txt

From: Sean Turner <[email-masked]>
Date: Mon, 5 May 2014 17:33:00 -0400

HI,

Some comments on the profile.  I only got to s9.

My general comment is that it would be great if there was one section that listed the differences between the base specification requirements and this/these profile/profiles.

0) abstract/s1/s2: Probably being pedantic here but aren’t there really
a number of different profiles in this drat?  There’s 3 sections and I assume
an implementer is just going to pick the one that suites there needs right and
not all of ‘em?

1) s1: The first sentence says “communications security” and later
“channel security” is used.  I guess I’d just pick one and stick with it.

2) s1: I’m not sure how the 1st goal is really do-able.   If it’s one-stop shop then I don’t have to go read any of the other specifications and this draft really can’t do.  Maybe it’s just that you want to provide a “roadmap” to help implementers figure out where to go to find more detail?  Maybe:

OLD:

   o  One-stop shop for implementers through the specification jungle.

   o  This document does not alter the DTLS 1.2 specification.

   o  This document does not introduce new extensions.

   o  This profile aligns with the DTLS security modes of the
      Constrained Application Protocol (CoAP) [I-D.ietf-core-coap].

NEW:

   o  Serve as a one-stop shop for implementers to know which pieces
       of the specification jungle contain relevant details.

   o  Not alter the DTLS specification.

   o  Not introduce any new extensions.

   o  Align with the DTLS security modes of the ….
      Constrained Application Protocol (CoAP) [I-D.ietf-core-coap].

3) s1: I think “using” isn’t needed in the following sentence:

    r/CoAP can be secured using a number of different ways,/
      CoAP can be secured a number of different ways,

4) s1: A pointer to the later sections would nice right before the intro to the
different security modes:

OLD:

These security modes are:

NEW:

These security modes are as follows, see Sections 4-6 for additional details:

5) s1, shared secret bullet: The bullets are about methods so maybe:

  r/This credential/This mode 

6) s1, cert-based bullet: In the following, maybe the 1st sentence
should be about “cryptography” as opposed to “credentials”:

      r/... using asymmetric credentials/
      ... asymmetric cryptography

7) s1, cert-based bullet:

  r/Two approaches for validating these public key are available./
    Two approaches for validating these public keys are available.

8) s1, 1st paragraph after the security mode bullets:  Maybe add
something about the security services so it leads better in to the next
sentences:

OLD:
   As described in [I-D.ietf-lwig-tls-minimal] an application designer
   developing an IoT device needs to think about the security threats
   that need to be mitigated. 

NEW:
   As described in [I-D.ietf-lwig-tls-minimal], an application designer
   developing an IoT device needs to consider the security threats
   and the security services that can be used to mitigate the threats.

9) s1, same paragraph as above but on the 2nd and 3rd sentences:
The “for many” sentence makes me wonder about the “some” that don’t
require authentication - which are those?  In the 3rd sentence, the need
for confidentiality lead in I understand but maybe the following would
work?:
 
OLD:
   For many Internet connected devices it
   is, however, likely that authentication of the device and the server
   infrastructure will be required.  Along with the ability to upload
   sensor data and to retrieve configuration information the need for
   integrity and confidentiality protection will arise.  

NEW:
  Enabling devices to upload data and retrieve configuration information,
  inevitably requires that Internet-connected devices be able to
  authenticate themselves to servers and vice versa as well as to ensure
  that the data and information exchanged is integrity and confidentiality
  protected.

10) s1, intro to DTLS vs TLS: I think you included the list for those
not familiar with the differences:

   r/As a short summary, for those familiar with TLS the differences
   are:/
   As a short summary, for those not familiar with DTLS the differences
   are:

11) s2, 1st paragraph:

When you say “Which server to contact is pre-configured", I assume
you’re talking about an IP address to directly contact the server or is
it a DNS servers address that will resolve a name?  Maybe it doesn’t
matter, but I’m curious nonetheless.  

The parenthetical about (in case of symmetric credentials) seems
redundant because PSK is the “symmetric credential”.

The section then later goes on to say the document is just about
client-side functionality but the previous paragraph is about some
server-side functionality.

Would the following work:

   Clients are preconfigured with the address or addresses of
   servers (e.g., as part of the firmware) they will communicate with
   as well as authentication information:

   o For PSK-based authentication (see Section 4), this includes the
   paired “PSK identity” and shared secret to be used with each server.

   o For raw public key-based authentication (see Section 5), this
  includes either the server’s public key or the hash of the server’s
  public key.

   o For certificate-based authentication (see Section 6), this may
  include a pre-populated trust anchor store that allows the client
  to perform path validation for the certificate obtained during the
  handshake with the server.

12) s2: Should this section address how many certificates should
be in the TA store?  Is there a discussion someplace about explicit
vs implicit trust stores (i.e., accept any certificate that chains to the
TA store)?

13) s3: Do we really need an entire section on how to read the
ciphersuite?  I’m not entire sure why the last paragraphs are
included.

14) I’m also not sure they were introduced by TLS and
the registry isn’t to keep track of them it’s to register them ;)  I’d
probably also add somewhere that the registered suites need to
indicate whether they apply to TLS, DTLS, or both.

OLD:
   TLS (and consequently DTLS) introduced the concept of ciphersuites
   and an IANA registry [IANA-TLS] was created to keep track of the
   specified suites.

NEW:
  TLS (and consequently DTLS) has the concept of ciphersuites
   and an IANA registry [IANA-TLS] was created to register the suites.

15)
s3, r/A ciphersuites/A ciphersuite
s3, r/Length(e.g.,/Length (e.g.,
s3, 5th bullet: r/(e.g./(e.g.,

16) s3: Wouldn’t it be better to describe the
TLS_PSK_WITH_AES_128_CCM_8 suite because it’s the one
mandated in [I-D.ietf-core-coap].

17) s4: I certainly don’t disagree that PSK is both computational
efficient and bandwidth conserving but it’s probably worth also
addressing the downside - i.e., no key management.  Shouldn’t
this section address how or maybe if there’s going to be any
ability to key rollover.  Kind of like the way s5 discusses firmware/
software update to update the key?

18) s4: Is the server always going to return the cookie?  I.e., is
it making the following SHOULD in RFC 5347 a MUST:

  Therefore, DTLS servers SHOULD use the cookie
  exchange unless there is good reason to believe that
  amplification is not a threat in their environment.

Actually, it might be good to have a section that highlights
any requirements that are different than those in the base
specifications.

19) s4: Is the following really a MUST NOT:

  For use with this profile the
  PSK identities MUST NOT assume a structured format (as domain names,
  Distinguished Names, or IP addresses have) and a bit-by-bit
  comparison operation can then be used by the server-side
  infrastructure.

Is the world going to end if I implement a server that does assume a
structured format - i.e., shouldn’t this really be a SHOULD NOT?

20) s4: R/Iot environments/IoT environments

21) s4: Should it be noted that the requirements on the server not sending
PSK identity and the client ignoring it as the same as in 4279?

22) s4: wrt the PSK lengths and identities, don’t we need to say what the new
requirements are if the old ones don’t apply?

23) s6: Is cached info required?

24) s6: wrt the question about depths.  I think we can safely say fewer is better ;)

25) s6: wrt multiple OCSP stapling it’s about an additional handshake to get the
rest of the path’s status.

   While
   multiple OCSP stapling [RFC6961] has recently been introduced as a
   mechanism to piggyback OCSP request/responses inside the DTLS/TLS
   handshake to avoid the cost of a separate protocol handshake to
   determine the entire certificate path’s status further
   investigations are needed to determine its suitability for the IoT
   environment.

26) s7: wrt to error codes, what’s the behavior for an error received that are not
applicable -silently ignored?

27) s9: Is the MUST NOT requirements a drop dead thing?  If I did implement it
would the world end?  I think this really ought to be a SHOULD NOT.

spt

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 06 May 2014 06:12:35 +0200

Hi Sean,

thanks for your review comments.

On 05/05/2014 11:33 PM, Sean Turner wrote:
> My general comment is that it would be great if there was one section
> that listed the differences between the base specification
> requirements and this/these profile/profiles.
> 
> 0) abstract/s1/s2: Probably being pedantic here but aren’t there
> really a number of different profiles in this drat?  There’s 3
> sections and I assume an implementer is just going to pick the one
> that suites there needs right and not all of ‘em?

It depends what you call a profile. For me it a profile was a reference
to the communication model, where a constrained client talks to a
regular TLS server.

> “channel security” is used.  I guess I’d just pick one and stick with

Makes sense.

> 
> 2) s1: I’m not sure how the 1st goal is really do-able.   If it’s
> one-stop shop then I don’t have to go read any of the other
> specifications and this draft really can’t do.  Maybe it’s just that
> you want to provide a “roadmap” to help implementers figure out where
> to go to find more detail?  Maybe:
> 
> OLD:
> 
> o  Serve as a one-stop shop for implementers to know which pieces of
> the specification jungle contain relevant details.
> 
> o  Align with the DTLS security modes of the …. Constrained
> Application Protocol (CoAP) [I-D.ietf-core-coap].
> 

Sounds good.

> r/CoAP can be secured using a number of different ways,/ CoAP can be
> secured a number of different ways,
> 
OK.

> 4) s1: A pointer to the later sections would nice right before the
> intro to the different security modes:
> 
> OLD:
> 

OK.

> r/This credential/This mode
OK.

> r/... using asymmetric credentials/ ... asymmetric cryptography
OK

> r/Two approaches for validating these public key are available./ Two
> approaches for validating these public keys are available.
OK

> something about the security services so it leads better in to the
> next sentences:
> 
> OLD: As described in [I-D.ietf-lwig-tls-minimal] an application
> designer developing an IoT device needs to think about the security
> threats that need to be mitigated.
> 
> NEW: As described in [I-D.ietf-lwig-tls-minimal], an application
> designer developing an IoT device needs to consider the security
> threats and the security services that can be used to mitigate the
> threats.
OK.

> 
> 9) s1, same paragraph as above but on the 2nd and 3rd sentences: The
> “for many” sentence makes me wonder about the “some” that don’t 
> require authentication - which are those?  In the 3rd sentence, the
> need for confidentiality lead in I understand but maybe the following
> would work?:
> 
> OLD: For many Internet connected devices it is, however, likely that
> authentication of the device and the server infrastructure will be
> required.  Along with the ability to upload sensor data and to
> retrieve configuration information the need for integrity and
> confidentiality protection will arise.
> 
> NEW: Enabling devices to upload data and retrieve configuration
> information, inevitably requires that Internet-connected devices be
> able to authenticate themselves to servers and vice versa as well as
> to ensure that the data and information exchanged is integrity and
> confidentiality protected.
OK

> 
> 10) s1, intro to DTLS vs TLS: I think you included the list for
> those not familiar with the differences:
> 
> are:/ As a short summary, for those not familiar with DTLS the
> differences are:

OK

> you’re talking about an IP address to directly contact the server or
> is it a DNS servers address that will resolve a name?  Maybe it
> doesn’t matter, but I’m curious nonetheless.

It should not matter in context of the DTLS profile as currently
described but I guess deployments will benefit from using the additional
layer of indirection with DNS.

> Clients are preconfigured with the address or addresses of servers
> (e.g., as part of the firmware) they will communicate with as well as
> authentication information:
> 
> include a pre-populated trust anchor store that allows the client to
> perform path validation for the certificate obtained during the 
Looks much better to have this structure.

> 12) s2: Should this section address how many certificates should be
> in the TA store?  Is there a discussion someplace about explicit vs
> implicit trust stores (i.e., accept any certificate that chains to
> the TA store)?

Good question.

I am not sure what guidance I should give.

> ciphersuite?  I’m not entire sure why the last paragraphs are 

I thought it would be useful background information.

> 
> 14) I’m also not sure they were introduced by TLS and the registry
> isn’t to keep track of them it’s to register them ;)  I’d probably
> also add somewhere that the registered suites need to indicate
> whether they apply to TLS, DTLS, or both.
> 
> OLD: TLS (and consequently DTLS) introduced the concept of
> ciphersuites and an IANA registry [IANA-TLS] was created to keep
> track of the specified suites.
> 
> NEW: TLS (and consequently DTLS) has the concept of ciphersuites and
> an IANA registry [IANA-TLS] was created to register the suites.
OK.

> 
> 15) s3, r/A ciphersuites/A ciphersuite s3, r/Length(e.g.,/Length
> (e.g., s3, 5th bullet: r/(e.g./(e.g.,
OK.

> TLS_PSK_WITH_AES_128_CCM_8 suite because it’s the one mandated in
> [I-D.ietf-core-coap].
Makes sense.

> addressing the downside - i.e., no key management.  Shouldn’t this
> section address how or maybe if there’s going to be any ability to
> key rollover.  Kind of like the way s5 discusses firmware/ software
> update to update the key?

In sense sense for the communication model presented in the document the
cert, raw public key, and the PSK use is somewhat similar. All require
an out-of-band mechanism (such as a firmware update protocol).

> 
> 18) s4: Is the server always going to return the cookie?  I.e., is it
> making the following SHOULD in RFC 5347 a MUST:
> 
> Therefore, DTLS servers SHOULD use the cookie exchange unless there
> is good reason to believe that amplification is not a threat in their
> environment.
> 
> Actually, it might be good to have a section that highlights any
> requirements that are different than those in the base 
> specifications.

I believe the client stack has to support it since otherwise it will not
be able to react on it when the server switches to the DoS protecting mode.

> For use with this profile the PSK identities MUST NOT assume a
> structured format (as domain names, Distinguished Names, or IP
> addresses have) and a bit-by-bit comparison operation can then be
> used by the server-side infrastructure.
> 

Re-reading the text, I believe the MUST NOT is indeed a bit strong.

> 20) s4: R/Iot environments/IoT environments
OK

> 
> 21) s4: Should it be noted that the requirements on the server not
> sending PSK identity and the client ignoring it as the same as in
> 4279?
> 
Added it

> 22) s4: wrt the PSK lengths and identities, don’t we need to say what
> the new requirements are if the old ones don’t apply?

I believe the entire discussion regarding PSK lengths and identitis in
RFC 4279 are just not applicable because they relate to the provisioning
model, which is very different in the embedded environment.

At least that's my thinking.

> 23) s6: Is cached info required?
Yes. Made this explicit.

> 24) s6: wrt the question about depths.  I think we can safely say

Yes, certainly ;-)

> 
> 25) s6: wrt multiple OCSP stapling it’s about an additional handshake
> to get the rest of the path’s status.

True. But for the embedded environment I have not heard anyone who plans
to use CRLs or OCSP. Instead the grand plan is to use the (not further
specified) software update mechanism....

> 
> While multiple OCSP stapling [RFC6961] has recently been introduced
> as a mechanism to piggyback OCSP request/responses inside the
> DTLS/TLS handshake to avoid the cost of a separate protocol handshake
> to determine the entire certificate path’s status further 
> 26) s7: wrt to error codes, what’s the behavior for an error received
> that are not applicable -silently ignored?

In general, I had the question what a DTLS should be doing with regards
to errors anyway. It can only re-try. It will rarely be able to log
something or notify the user..

> 
> 27) s9: Is the MUST NOT requirements a drop dead thing?  If I did
> implement it would the world end?  I think this really ought to be a
> SHOULD NOT.

I wonder whether a MUST NOT has to be placed on the compression.

Ciao
Hannes

> 
> spt _______________________________________________ dtls-iot mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dtls-iot
>