[Iotops] comments on draft-ietf-uta-tls13-iot-profile-04:

[Michael Richardson <[e-mail]>]

I read draft-ietf-uta-tls13-iot-profile-04 today.
Thank you Hannes for presenting it at IOTOPS.  To be, it is precisely this
kind of thing that IOTOPS was created for.

1) I feel that the 4.25 Too Early allocation for CoAP could use a bit more
   explanation, and probably there needs to be some more clear review at CORE.
   (maybe it already happened and I missed it?)
   Reading through the lines, it appears that a server that can't handle
   early data needs to send an error code.  But such a server probably
   doesn't know about the error code.  I would have thought it should just
   hang on to the data until the (D)TLS negotiation is complete.
   I'm also concerned that this requires too much cross-layer communication
   between DTLS layer and CoAP layer.

2) A long thread at LAMPS two years suggests that the term "Intermediate CA"
   applies only to cross-certification authoritiy bridges, and the term
   "Subordinate CA" should be used.  That this is consistent with history
   going back to RFC4949.

3) While section 10 on SNI does not say *how* to use DoH or DPRIVE to provide
   for confidentiality of names that are looked up, a naive use of DoH with
   Google/Cloudflare/etc. by IoT devices would be a problem for almost all
   enterprises that wish to filter the DNS used by IoT devices, and to use
   DNS canaries to identify malware.

Given that such an involved discussion is not in scope for this document,
it might be better just to refer to the ADD WG without mentioning specific
solutions.
I am, in general, not convinced that encrypted SNI serves any purpose for
most IoT devices.

4) section 15
   There is much discussion about what goes into the certificates.
   I didn't really understand why that is in this document.
   Validation of server certificates is well covered in RFC6125, I think.

Validation of client certificates (whether factory provisioned IDevIDs, or
locally enrolled LDevIDs) is a topic that I care a lot about, and
this text is inadequate.

As the (industrial) IoT market embraces IDevID certificates, there is some
concern that different markets will put different requirements on IDevID
contents.  So far it does not appear that anyone has created a situation
where a single (fat) IDevID certificate couldn't be used in a variety of
market verticals, the concern remains.

It was my intention to introduce a document about this issue. I think that
it's something that only the IETF can do.  Perhaps that would fit into this
UTA document, or perhaps parts of this section 15 goes into another document.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-