Subject: Re: [Dtls-iot] Fwd: [dice] #6 (profile): Trusted CA Indication

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Jul 2014 13:42:38 -0400

On 6/21/2014 2:19 PM, Hannes Tschofenig wrote:
>
>
> -------- Original Message --------
> Subject: [dice] #6 (profile): Trusted CA Indication
> Date: Fri, 20 Jun 2014 15:11:36 -0000
> From: dice issue tracker <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
>
> #6: Trusted CA Indication
>
>   This RFC 6066 extension allows clients to indicate what trust anchor they
>   support. This is useful only when the IoT device has not been pre-
>   provisioned with information about the trust anchors the server-side
>   supports.
>
>   In most IoT deployments, however, there is a rather fixed relationship
>   between the IoT device (and the software running on them) and the server-
>   side infrastructure and no such dynamic indication of trust anchors is
>   needed.
>
>   Recommendation: General recommendation is that this is not useful. Add
>   info in which environment this would add value.
>

I don't necessarily disagree with this recommendation, but it may be 
hiding the point that there may be pre and post enrollment  issues. E.g. 
before enrollment, the IoT node knows the trust anchor for its 
manufacturer, and so is looking for some sort of enrollment credential 
from the server; post enrollment the node has the trust anchor as 
indicated above.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Jul 2014 20:01:20 +0200

Hi Mike,

here is what I put into the latest version of the document:

----

   RFC 6066 allows clients to indicate what trust anchor
   they support.  With certificate-based authentication a DTLS server
   conveys its end entity certificate to the client during the DTLS
   exchange provides.  Since the server does not necessarily know what
   trust anchors the client has stored it includes intermediate CA certs
   in the certificate payload as well to facilitate with certification
   path construction and path validation.

   Today, in most IoT deployments there is a fairly static relationship
   between the IoT device (and the software running on them) and the
   server- side infrastructure and no such dynamic indication of trust
   anchors is needed.

   Recommendation: For IoT deployments where clients talk to a fixed,
   pre-configured set of servers and where a software update mechanism
   is available this extension is not recommended.  Environments where
   the client needs to interact with dynamically discovered DTLS servers
   this extension may be useful to reduce the communication overhead.
   Note, however, in that case the TLS cached info extension may help to
   reduce the communication overhead for everything but the first
   protocol interaction.

----

You are certainly right that there are firmware update and device
management protocols involved that help make this task manageable.

Maybe it would make sense to talk briefly about this issue in the
introduction.

Ciao
Hannes

On 07/17/2014 07:42 PM, Michael StJohns wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot