Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
RFC 7925
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
Alvaro Retana No Objection
(Ben Campbell; former steering group member) Yes
Thanks for a clear, easy to read document. At the start, I considered complaining about the page count, but I think you used those pages well. 4.4.1, paragraph after first numbered list: Can this be more precise than "breaks security"? Maybe something to the effect of "Comparing...is required to ensure the client is communicating with the intended server"? 4.4.3, and 23: Are there bootstrapping concerns with software update mechanisms? For example, what if you need to revoke a trust anchor on which the update mechanism depends?
(Kathleen Moriarty; former steering group member) Yes
Thanks for your work on this draft! It is very well written and provides helpful guidance with appropriate pointers that I hope gets picked up by many IoT vendors. I even tweeted about this one! It would be good to raise awareness on this draft/RFC. Nice job!
(Spencer Dawkins; former steering group member) Yes
I really like this document. I wish more working groups produced similar guidance.
I did have a number of questions, that you might want to take a look at before the document is approved.
This text
UDP is mainly used to carry CoAP messages but other
transports can be utilized, such as SMS Appendix A or TCP
[I-D.tschofenig-core-coap-tcp-tls].
is somewhat ambiguous - is this supposed to say that "Most CoAP messages are carried in UDP, but other transports can be utilized, such as ..."?
This document is pretty reference-rich, but
For use with this profile the PSK identities
SHOULD NOT assume a structured format (such as domain names,
Distinguished Names, or IP addresses) and a constant time bit-by-bit
comparison operation MUST be used by the server for any operation
related to the PSK identity.
doesn't have a reference or a definition for "constant time bit-by-bit comparison operation". Could you provide one?
I wasn't quite sure what
TLS/DTLS offers a lot of freedom for the use with ECC.
means. At a minimum, "for the use with" needs help. I'm guessing from the rest of the paragraph that this is saying "TLS/DTLS offers a lot of choices when selecting ECC curves", or something like that. But I'm guessing.
Is there a missing word in
For deployments
where public key cryptography is acceptable the raw public might
somewhere around here? ^
offer an acceptable middle ground between the PSK ciphersuite in
terms of out-of-band validation and the functionality offered by
asymmetric cryptography.
I think I understand
The use of PFS is a trade-off decision since on one hand the
compromise of long-term secrets of embedded devices is more likely
than with many other Internet hosts but on the other hand a Diffie-
Hellman exchange requires ephemeral key pairs to be generated, which
is demanding from a performance point of view. For obvious
performance improvement, some implementations re-use key pairs over
multiple exchanges (rather than generating new keys for each
exchange). However, note that such key re-use over long periods
voids the benefits of forward secrecy when an attack gains access to
this DH key pair.
but, just to make sure - is this saying that when you gain access to a DH key pair, you can decrypt back to the last time the device generated new keys, but no further (so, "Imperfect Forward Secrecy")? I'm guessing that based on "trade-off" in the first sentence, but I'm not sure what's being traded for performance improvement.
In this text,
On the other hand, the way DTLS handles
retransmission, which is per-flight instead of per-segment, tends to
interact poorly with low bandwidth networks.
I'm assuming you are using "per-flight" in the https://tools.ietf.org/html/rfc5681 sense of the term ("FLIGHT SIZE: The amount of data that has been sent but not yet cumulatively acknowledged"), but that's somewhat obscure, especially outside of TSV, and there's no definition or reference for it in this document. Perhaps you could say something like
On the other hand, DTLS handles loss by retransmitting the
entire amount of data that has been sent but has not been
cumulatively acknowledged, and this tends to
interact poorly with low bandwidth networks.
Just to make sure I understand,
The ClientHello and the ServerHello messages contains the 'Random'
structure, which has two components: gmt_unix_time and a sequence of
28 random bytes. gmt_unix_time holds the current time and date in
standard UNIX 32-bit format (seconds since the midnight starting Jan
1, 1970, GMT). Since many IoT devices do not have access to an
accurate clock, it is RECOMMENDED to place a sequence of random bytes
in the two components of the 'Random' structure when creating a
ClientHello or ServerHello message and not to assume a structure when
receiving these payloads.
is recommending that all IoT devices use a sequence of random bytes, even if they do have access to an accurate clock - is that right?
Could you help me understand why
Implementing the Server Name Indication extension is RECOMMENDED
unless it is known that a TLS/DTLS client does not interact with a
server in a hosting environment.
isn't REQUIRED? This seems like a violation of the Principle of Least Astonishment ("we moved our server into a hosted environment to save money, and our sensor network quit working").
I don't understand this paragraph.
To prevent the re-negotiation attack [RFC5746] this specification
RECOMMENDS to disable the TLS renegotiation feature. Clients MUST
respond to server-initiated re-negotiation attempts with an alert
message (no_renegotiation) and clients MUST NOT initiate them.
If you MUST tell the server you won't renegotiate, and you MUST not try to renegotiate yourself, how does these turn into a RECOMMENDS ("SHOULD")?
(Stephen Farrell; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
Just some editorial comments here that the RFC Editor isn't likely to catch: -- Section 1 -- UDP is mainly used to carry CoAP messages but other transports can be utilized This is worded oddly, as it looks as if it's saying that the main use of UDP is to carry CoAP messages. Please consider this instead: NEW CoAP messages are mainly carried over UDP, but other transports can be utilized END -- Section 3.1 -- However, since DTLS operates on top of an unreliable datagram transport, it must explicitly cope with the reliable and ordered delivery assumptions made by TLS. It must explicitly cope with the *absence of* reliable and ordered delivery. Please consider re-wording this. -- Section 4.4.4 -- There are various algorithms used to sign digital certificates, such as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). As Table 1 indicates certificate are signed using ECDSA. This initially confused me. First, the "such as" modifier appears to apply to "digital certificates", when it's actually meant to apply to "algorithms". Then the second sentence seemed to contradict the first, until I realized that it's incomplete. Please consider this: NEW There are various algorithms used to sign digital certificates; those algorithms include RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). As Table 1 shows, in this profile certificates are signed using ECDSA. END -- Section 4.4.6 -- With certificate-based authentication a DTLS server conveys its end entity certificate to the client during the DTLS exchange provides. Something's wrong with this sentence (the part that begins with "during"), but I can't figure out what. -- Section 6 -- All error messages marked as RESERVED are only supported for backwards compatibility with SSL MUST NOT be used with this profile. You're missing "and" before "MUST NOT". -- Section 13 -- Implementations conformant to this specification MUST use AEAD ciphers. Hence, RFC 7366 and the Truncated MAC extension of RFC 6066 are not applicable to this specification and are NOT RECOMMENDED. To me, "not applicable" says more than "NOT RECOMMENDED". Why is this not "MUST NOT be used"? -- Section 17 -- To prevent the re-negotiation attack [RFC5746] this specification RECOMMENDS to disable the TLS renegotiation feature. Clients MUST respond to server-initiated re-negotiation attempts with an alert message (no_renegotiation) and clients MUST NOT initiate them. Doesn't the second sentence actually say that this specification REQUIRES (not "RECOMMENDS") disabling of the TLS renegotiation feature? -- Section 18 -- If at some time in the future this profile reaches the quality of SSL 3.0 a software update is needed since constrained devices are unlikely to run multiple TLS/DTLS versions due to memory size restrictions. I don't understand this. What does "reaches the quality of SSL 3.0" mean?
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection