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

From: Ludwig Seitz <[email-masked]>
Date: Mon, 02 Mar 2015 10:11:04 +0100

On 01/26/2015 02:28 PM, Zach Shelby wrote:
> 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
>

Hello list,

although the WGLC has ended, I have been asked to provide an additional 
review by Hannes Tschofenig, which I hereby do.

I have divided my findings into "issues", "typos" and "nits":

Issues (3):

Section 4.1.1.2. CoAP-based Data Exchange Example

I'm not sure that the Resource Directory is intended to relay requests. 
To my knowledge it is just intended as a lookup service to find out 
metadata about available resources. It would be good to check this with 
e.g. Zach or Carsten.

---
Section 6

Is it intentional that section 6 mandates that a device that wants to 
comply with this profile MUST implement ALL OF 6.1, 6.2 and 6.3?

So a device just implementing DTLS PSK mode with the guidance from 6.1 
would not be considered compliant?

If the answer is yes, this seems to place quite a code-size burden
on constrained devices.

---
Section 9. Session Resumption

Note that the TLS WG discussed dropping session resumption for
TLS 1.3 during IETF 89, see slide 4 in
http://www.ietf.org/proceedings/89/slides/slides-89-tls-5.pdf.
We should check the status of this before we produce RFCs that rely on 
this mechanism.

======================================================================
Typos (6):

3.  TLS/DTLS Protocol Overview, second bullet

"is exclusive-ORed with an dentical amount"

Should read "identical"
---
"Figure 2: Network Access Architecture.."

Remove last period.
---
Figure 6  Local Discovery and Resouce Access.

The "Configure ..." arrow is missing its arrowhead.
---
5. The TLS/DTLS Ciphersuite Concept, 5th bullet

"(e.g., HMAC with the SHA-256)"

delete "the"
---
8.  Error Handling

"Those include decryption_failed_RESERVED, no_certificate_RESERVE, and 
export_restriction_RESERVED."

should read "no_certificate_RESERVED" (give us a 'D'!)
---
14.  Random Number Generation
"Since many IoT devices do not have access to a real-time clock this 
recommendation it is RECOMMENDED to follow the guidance outlined in ..."

delete "this recommendation"
=======================================================================
Nits (10):

Abstract:
This gives the impression that we are only dealing with devices 
providing data in form of e.g. sensor readings. An equally common 
pattern would be an actuator that controls some physical system, like a 
valve, a thermostat or a smart light bulb.

---

3.  TLS/DTLS Protocol Overview, first paragraph

"The protocol is composed of two layers: the Record Protocol and the 
Handshake Protocol."

There are actually two other protocols in TLS/DTLS, the change cipher
spec protocol and the alert protocol, although they are subsumed 
together with the handshake protocol as the "handshaking protocols" in 
the RFC.

---
3.  TLS/DTLS Protocol Overview, last bullet

"Furthermore, the handshake message format has been extended to deal 
with message loss, reordering, and fragmentation.  Retransmission timers 
have been included to deal with message loss."

This sounds weird due to the repetition of "message loss". Does the 
message format really have any role in dealing with message loss?

---
4.1.1.1.  Network Access Authentication Example, second paragraph

"To route EAP messages ..., name RADIUS or Diameter."

A citation of the rfcs would be appropriate here
[RFC2865] and [RFC6733].

---
4.1.1.1.  Network Access Authentication Example, pages 7-8

"The EAP-TLS exchange is shown in Figure 3 where it is worthwhile to 
point out that in EAP the client / server roles are reversed but with 
the use of EAP-TLS the IoT device acts as a TLS client.

This last sentence is unclear, reversed with respect to what? Does the
TLS client become the EAP server?
---
4.1.1.2.  CoAP-based Data Exchange Example, second paragraph

"Figure 4 shows a sensor starting with a DTLS exchange with a resource
    directory to register available resources."

I'd remove the first "with"
---
6.3.  Certificates, page 22

"Note that the Service Name ... to convey EUI-64 identifiers."

The citation [EUI64] appearing later in the text should be here instead.
---
8. Error Handling
"TLS/DTLS uses the Alert protocol to convey error messages and 
specifies a longer list of errors."

Longer than what?
---
14.  Random Number Generation
"Special care has to be paid when generating random numbers ..."

"pay attention" but "take care", I'd say "Special care has to be
taken..."
---
14.  Random Number Generation

followed by a random sequence of 28 random bytes

delete the first "random"

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 16:18:34 +0100

Hi Olaf,

thanks for the review.

On 02/07/2015 12:42 AM, Olaf Bergmann wrote:
> Zach Shelby <[email-masked]> writes:
> 
> 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?

I included a reference to the CCM specification, which discusses these
aspects.

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

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

Do you see use of the "PSK identity hint" or do you suggest to change
the sentence to: "Clients MUST ignore the message.'?

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

I believe we are OK not following that recommendation since it was given
in a different context, namely with regards to the ability for the
browser to accept certain type of identities from the user. In our case,
we are defining a profile for a different deployment environment.

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

Added text.

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

I added a note that this has to be agreed out-of-band between the client
and the server. This is not ideal but on the other hand the client must
not trust a random server to provide time information.

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

Fixed.

> 
> A few editorial nits (besides Mathias's):
> 
>  * in Section 4.2, 2nd para: s/endpointas/endpoints/
Fixed.

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

Fixed.

>  * In Section 6.2, the subtitle of Figure 8 denotes that the Cookie
>    Exchange is shown, which is not.
Fixed.

> 
>  * References
>    [ACE-WG] is dated "Jan 2015". Do you mean 2014?

I used the date when I retrieved the page rather than when it was formed.

>    s/Tripple-HS/Triple-HS/  (Referenced in Section 18)

Fixed.

Ciao
Hannes

> 
> 
> Grüße
> Olaf
> 
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 16:18:34 +0100

Hi Olaf,

thanks for the review.

;-)

Done.

Added text.

Fixed.

Fixed.

Fixed.

Fixed.

Fixed.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 05 Mar 2015 18:14:18 +0100

Hi Hannes,

> the sentence to: "Clients MUST ignore the message.'?

I envision that the identity hint is used exactly the same in the IoT as
in the rest of the world. I see no reason why this should be different
in constrained environments.

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 19:37:41 +0100

Hi Olaf,

the original reason why Pasi and I added the "PSK identity hint" to the
TLS-PSK specification was the desire to interwork with the 3GPP Generic
Bootstrapping Architecture. The GBA was the key management protocol used
to distribute the PSK to the server-side.

I don't think anyone is planning to use this stuff anymore today.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 05 Mar 2015 20:55:02 +0100

> to distribute the PSK to the server-side.

Oh, I see. Until now, my reading was that this is used as a sort of
realm indicator. If your assessment is correct that nobody uses it,
I would be in favor of the "client MUST ignore" version.

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 21:04:06 +0100

You could use it as a realm-indicator as well but in the meanwhile the
SNI stuff had been defined that allows the client to indicate what
server it wants to choose (in a hosting solution). While this is not
exactly the same I am not sure anyone has used the PSK identity hint in
a realm-selection scenario.

It would be good to know whether anyone has seen a need for it in the
IoT context. If so, we could change the text and add some motivation for
where to use it.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 06 Mar 2015 12:25:03 +0100

Hi Hannes,

> IoT context. If so, we could change the text and add some motivation for

FWIW: I have added support for the PSK identity hint to tinydtls a while
ago on explicit request. I'd see this as a weak indicator that it is
used at least by someone.

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Mar 2015 12:55:21 +0100

Olaf, that's interesting.

Do you remember what the use case of the person asking for the support
of the PSK identity hint was?

Has someone else in the working group encountered the need for the PSK
identity hint?

I am happy to add support back into the spec for it.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 06 Mar 2015 15:47:51 +0100

> of the PSK identity hint was?

Not really. From my old emails, I cannot tell if there was a real use
case behind that request. Maybe not.

Grüße
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Mar 2015 19:55:26 +0100

Hi Ludwig,

thanks for your very detailed review.

I have addressed all your review comments, as you can see below.

> metadata about available resources. It would be good to check this with

I added a note that the description shows OMA LWM2M, which uses RD.

> comply with this profile MUST implement ALL OF 6.1, 6.2 and 6.3
> 

I added a note that clarifies this aspect. Of course, a device that only
uses PSK-based credential only has to implement the recommendations
outlined in Section 6.1.

> We should check the status of this before we produce RFCs that rely on

I understand the concern but we definitely do not to wait until the work
on TLS 1.3 is finalized.

Fixed.

Fixed.

Fixed.

Fixed.

Fixed.

Fixed.

Fixed.

> together with the handshake protocol as the "handshaking protocols" in

That's correct. I updated the description but I wanted to keep it as
simple as possible. The problem is that the TLS terminology isn't all
that great and the design is somewhat chaotic.

Fixed.

> A citation of the rfcs would be appropriate here

Added.

> TLS client become the EAP server?

Clarified it. I believe the role change between the client and the
server in EAP and the EAP method is not that relevant for this document.

Fixed.

Fixed.

> ---
> 8. Error Handling
> "TLS/DTLS uses the Alert protocol to convey error messages and specifies
> a longer list of errors."
> 
> Longer than what?

Fixed.

Fixed.

Fixed.

Ciao
Hannes

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Sat, 7 Mar 2015 10:37:48 +0000

Hi Hannes

There are situations where the PSK Identity hint is still useful.
In certain personalization contexts (like in SIM cards or HSMs) a large block of data is securely provisioned to the device at once from which different portions of this data block are used as keys during different lifecycle stages. The PSK identity hint could be used as an offset to indicate which part of the key-block is in use for a particular DTLS handshake.

The other case is related to use of DTLS with polynomial based identity based cryptosystems [1] [2] where the PSK Identity hint can be used to derive the mutual PSK key that should be used between the client and server.

Since PSK identity hint is already optional in the first case, keeping it in the profile that way would not lead to additional overhead and can be still used for deployments that may find it useful.

regards
Sandeep

[1]Blundo, C., De Santis, A., Herzberg, A., Kutten, S., Vaccaro, U., and Yung, M. "Perfectly-Secure Key Distribution for Dynamic Conferences", Advances in Cryptology (CRYPTO'92), 1993.
[2]Oscar Garcia-Morchon and Ronald Rietman and Sahil Sharma and Ludo Tolhuizen and Jose Luis Torre-Arce, DTLS-HIMMO: Efficiently Securing a Post-Quantum World with a Fully-Collusion Resistant KPS https://eprint.iacr.org/2014/1008

Sent from Windows Mail

From: Hannes Tschofenig<mailto:[email-masked]>
Sent: ‎Thursday‎, ‎March‎ ‎5‎, ‎2015 ‎9‎:‎04‎ ‎PM
To: Olaf Bergmann<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Ciao
Hannes

> I would be in favor of the "client MUST ignore" version.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 07 Mar 2015 12:58:38 +0100

Hi Sandeep,

here is a detailed description of how TLS-PSK was used with the GBA:
http://www.3gpp.org/ftp/tsg_sa/wg3_security/tsgs3_33_beijing/docs/pdf/s3-040337.pdf

As you can see the psk identity hint is needed since the PSK is selected
based on the BSF but the TLS client contacts the NAF.

This is IMHO a technical reason but, as mentioned earlier in the
discussion with Olaf, I believe GBA is dead and maybe I am wrong.

In the examples you mention below there is no enough detail to see
whether the psk identity hint is really needed.

I am a bit reluctant to just add functionality based on vague ideas
since this is the source of complexity in the IoT environment. There are
many places in the document where we could have added various other
features. In fact, I would encourage everyone to go through the document
to find out whether there is functionality we could avoid to reduce
complexity even further.

I have a fairly strong opinion about identity-based encryption. As I had
stated in other discussions (see, for example,
https://www.ietf.org/mail-archive/web/emu/current/msg01830.html), I
believe that identity-based encryption is a solution in search of a
problem.
It does not solve any of the problems we have in the IoT security space.

In general, I believe we are well advised to take a look at the Smart
Object workshop position paper from Carsten again since it relates to
this discussion:
https://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf

But despite my resistance I am really just looking for someone who is
deploying the identity hints with PSK and could provides more details on
how they use it. In fact, with the recent review from Rene I have
removed the text about the identity hint from the profile document since
it was indeed inconsistent in the recommendation it provided. Better to
say nothing about it.

Ciao
Hannes

On 03/07/2015 11:37 AM, Kumar, Sandeep wrote:
> In certain personalization contexts (like in SIM cards or HSMs) a large
> block of data is securely provisioned to the device at once from which
> different portions of this data block are used as keys during different
> lifecycle stages. The PSK identity hint could be used as an offset to
> indicate which part of the key-block is in use for a particular
> DTLS handshake.
> 
> The other case is related to use of DTLS with polynomial based identity
> based cryptosystems [1] [2] where the PSK Identity hint can be used
> to derive the mutual PSK key that should be used between the client and
> server.
> 
> Since PSK identity hint is already optional in the first case, keeping
> it in the profile that way would not lead to additional overhead and can
> be still used for deployments that may find it useful.
> 
> 
> regards
> Sandeep
> 
> [1]Blundo, C., De Santis, A., Herzberg, A., Kutten, S., Vaccaro, U., and
> Yung, M. "Perfectly-Secure Key Distribution for Dynamic Conferences",
> Advances in Cryptology (CRYPTO'92), 1993.
> [2]Oscar Garcia-Morchon and Ronald Rietman and Sahil Sharma and Ludo
> Tolhuizen and Jose Luis Torre-Arce, DTLS-HIMMO: Efficiently Securing a
> Post-Quantum World with a Fully-Collusion Resistant KPS
> https://eprint.iacr.org/2014/1008 
> 
> Sent from Windows Mail
> 
> *From:* Hannes Tschofenig <mailto:[email-masked]>
> *Sent:* ‎Thursday‎, ‎March‎ ‎5‎, ‎2015 ‎9‎:‎04‎ ‎PM
> *To:* Olaf Bergmann <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> 
> ------------------------------------------------------------------------
> The information contained in this message may be confidential and
> legally protected under applicable law. The message is intended solely
> for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, forwarding, dissemination, or reproduction
> of this message is strictly prohibited and may be unlawful. If you are
> not the intended recipient, please contact the sender by return e-mail
> and destroy all copies of the original message.