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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
