[Dtls-iot] Barry Leiba's No Objection on draft-ietf-dice-profile-16: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-dice-profile-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dice-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?