Subject: [Dtls-iot] Fwd: Comments on draft-ietf-dice-profile

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Dec 2014 09:03:10 +0100

Ekr provided a review and I have incorporated his feedback into the
document.

Here is the work-in-progress version:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-08.txt

Ciao
Hannes

-------- Forwarded Message --------
Subject: 	Comments on draft-ietf-dice-profile
Resent-To: 	[email-masked]
Date: 	Thu, 4 Dec 2014 10:36:48 -0800
From: 	Eric Rescorla <[email-masked]>
To: 	[email-masked]

Hannes,

I took a look at this draft. Some comments below.

OVERALL
This seems generally pretty good.

I would try to be more clear about whats just advice and what's
normative. In particular, it's odd to have "Recommendation: You MUST..."

I wouldn't bother with showing the cookie exchange in any but the first
ladder diagram. Also, maybe make extensions clearer by indenting them
or putting them in parentheses or something.

DETAILS
S 1.
Suggest explaining that "stream" here is a TLS technical term and that
e.g., CTR mode is not a stream cipher in this context.

S 5.1.
   The client indicates which key it uses by including a "PSK identity"
   in the ClientKeyExchange message.  As described in Section 3 clients
   may have multiple pre-shared keys with a single server and to help
   the client in selecting which PSK identity / PSK pair to use, the
   server can provide a "PSK identity hint" in the ServerKeyExchange
   message.  If the hint for PSK key selection is based on the domain
   name of the server then servers SHOULD NOT send the "PSK identity
   hint" in the ServerKeyExchange message.  Hence, servers SHOULD NOT
   send the "PSK identity hint" in the ServerKeyExchange message and
   client MUST ignore the message.  This approach is inline with RFC
   4279 [RFC4279].  Note: The TLS Server Name Indication (SNI) extension
   allows the client to tell a server the name of the server it is
   contacting, which is relevant for hosting environments.  A server
   using the identity hint needs to guide the selection based on a
   received SNI value from the client.

I have read this several times and I'm not sure what it means. Is
it just saying "don't send identity hints" plus some explanation of why?
If so, perhaps a rewrite.

   RFC 4279 requires TLS implementations supporting PSK ciphersuites to
   support arbitrary PSK identities up to 128 octets in length, and
   arbitrary PSKs up to 64 octets in length.  This is a useful
   assumption for TLS stacks used in the desktop and mobile environment
   where management interfaces are used to provision identities and
   keys.  For the IoT environment, however, many devices are not
   equipped with displays and input devices (e.g., keyboards).  Hence,
   keys are distributed as part of hardware modules or are embedded into
   the firmware.  As such, these restrictions are not applicable to this
   profile.

EKR: This is a normative statement, right? Please make it so.

S 5.2.
   1.2 and utilizes an eight-octet authentication tag.  The use of a
   Diffie-Hellman key exchange adds perfect forward secrecy (PFS).  More

"Elliptic Curve Diffie-Hellman". Also perhaps "provides" rather
than adds.

S 5.3.
   contains the root certificates.  The use of the Trust Anchor
   Management Protocol (TAMP) [RFC5934] is, however, not envisioned.
   Instead IoT devices using this profile MUST rely a software update
   mechanism to provision these trust anchors.

I don't really understand this last statement.

S 6.
   insufficient_security:  This error message indicates that the server
      requires ciphers to be more secure.  This document does, however,
      specify the only acceptable ciphersuites and client
      implementations must support them.

I don't really believe this because of the usual versioning reasons.

S 8.
   This DTLS client profile does not include DTLS layer compression.

Maybe say "MUST NOT use"

S 13.
   Recommendation: For IoT deployments where clients talk to a fixed,
   pre-configured set of servers and where a software update mechanism
   is available this extension is not recommended.  Environments where
   the client needs to interact with dynamically discovered DTLS servers
   this extension may be useful to reduce the communication overhead.
   Note, however, in that case the TLS cached info extension may help to
   reduce the communication overhead for everything but the first
   protocol interaction.

this is pretty fuzzy

S 14.
   Recommendation: Since this profile only supports AEAD ciphersuites
   this extension is not applicable.

Why is this not a MUST NOT?

S 17.
   Recommendation: Client implementations SHOULD implement this
   extension support this extension even though the ciphersuites
   recommended by this profile are not vulnerable this attack.

You should double-check this against the triple handshake paper.

-Ekr