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

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

Thanks for your review.

Let me provide you my remarks below.

-----Original Message-----
From: Michael Richardson <[e-mail]>
Sent: Saturday, March 26, 2022 1:42 PM
To: [e-mail]; [e-mail]; [e-mail]
Cc: Hannes Tschofenig <[e-mail]>
Subject: comments on draft-ietf-uta-tls13-iot-profile-04:


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.

[hannes] With the design we are following the corresponding design of HTTP. Thomas has sent a mail already to solicit feedback.

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.

[hannes] We can note in the terminology section that the terms "Intermediate CA" and "Subordinate CA" are used interchangeably in this document because with regards to this document the distinction is not relevant.

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.

[hannes] Major IoT service providers have cared about hiding client identity information by utilizing session resumption in TLS 1.2 to accomplish what is now available in TLS 1.3 with earlier encryption of handshake messages. While I personally haven't heard anyone asking for SNI encryption yet, I expect the same companies who cared about hiding the client identifiers to also take a look at the SNI encryption. While there are pros and cons of using these mechanisms, I am only suggesting to reference ongoing IETF work.  Companies then need to decide whether a specific solution matches their requirements.


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.

[hannes] In my experience, validation of server certificates has been a source of confusion in IoT and RFC 6125 does not talk about the use of IoT protocols like CoAP and MQTT. I have seen various companies and organizations creating their own profiles of RFC 6125 in the past, which has resulted in the text of this section.

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.

[hannes] This section was difficult to write because
- there are lots of different IoT verticals,
- companies often do not want to share information about what they do in their deployments, and
- there are many different identifier formats.

It would, of course, be worthwhile to ask around again to see what current deployments are using. I could check the public documentation of major IoT service providers to get this process started.

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.