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

From: Olaf Bergmann <[email-masked]>
Date: Sat, 07 Feb 2015 00:42:16 +0100

Zach Shelby <[email-masked]> writes:

> This mail kicks off a 2nd WGLC for our DTLS profile draft:
>
> https://tools.ietf.org/html/draft-ietf-dice-profile-09 

Zach, Hannes, Thomas,

sorry for being very late with my review. This I-D is a very good read
with substantial information (not repeating here the usual caveat that
you will most likely have the four-party scenario with multiple AA
servers instead of only three; for this profile document, I am ok with
the simplistic view of Section 4.1).

Some minor remarks:

Section 5 talks about the length of the authentication tag and refers to
"_8" as possibly being used in constrained networks.  Maybe it would be
good to mention that shortening the tag has impact on the collision
probability?

In the last paragraph of Section 5, you could add that SHA-256 is the
recommended default PRF.

In Section 6.1, I am also not sure that 'servers SHOULD NOT send the
"PSK identity hint" in the ServerKeyExchange message and client MUST
ignore the message.' I do not see why this recommendation is needed.
(The client may ignore it anyway, and the server cannot assume that a
client reacts on the identity hint the server sends.)

"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." -- This is a contradiction to RFC 4279 which states that
implementations MUST support these lengths but MAY support longer
psk_identities and keys. Although it does not always make sense and is
not recommended to use psk_identities longer than 128 octets and keys
that are longer than 64 octets _in the IoT environment_, we must not
restrict implementations in this regard.

The second paragraph in Section 9 starts with "Constrained clients MUST
implement session resumption to improve the performance of the
handshake."  This is correct, and there is no problem with it but it
made me stumble when reading it for the first time. Maybe you could add
a note that a client that is not capable of storing the state (e.g.,
during reboot) can always decide to send an empty session_id.

I am not sure I understand what the following paragraph from Section 14
actually recommends:

   "[...] for the ServerHello.Random structure it is RECOMMENDED to
   maintain the existing structure with gmt_unix_time followed by a
   random sequence of 28 random bytes since the client can use the
   received time information to securely obtain time information.  For
   constrained servers it cannot be assumed that they maintain accurate
   time information; these devices MUST include time information in the
   Server.Random structure when they actually obtain accurate time
   information that can be utilized by clients.  Clients MUST only use
   time information obtained from servers they trust."

Now, how can the client tell whether or not the first 4 bytes of
ServerHello.Random contains accurate time information? Is this knowledge
obtained out-of-band as the last sentence ("trust") might indicate?

The last sentence of Section 15 about truncated MAC says "RFC 6066 MUST
not be implemented", whereas the last sentence of the following Section
16 on SNI starts with "This specification RECOMMENDs the implementation
of RFC 6066". This could be misleading and should probably qualified by
specifying which part of RFC 6066 is referred to.

A few editorial nits (besides Mathias's):

 * in Section 4.2, 2nd para: s/endpointas/endpoints/
 * The doubled reference to RFC 7390 in the 2nd paragraph
   of "Discovery and Reachability" ("RFC 7390 [RFC7390] describes")
   is a bit weird. (Same for RFC 6655 in the 2nd paragraph in
   Section 5, RFC 6090 in Section 6.2, RFC 6125, 6066 in Section 6.3)
 * In Section 6.2, the subtitle of Figure 8 denotes that the Cookie
   Exchange is shown, which is not.

 * References
   [ACE-WG] is dated "Jan 2015". Do you mean 2014?
   s/Tripple-HS/Triple-HS/  (Referenced in Section 18)

Grüße
Olaf