Subject: [core] draft-ietf-core-coap-06 What protocol

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 May 2011 20:48:34 -0600

Given a CoAP URI like coap:1.2.3.4/temp, do I try to connect with DTLS or UDP?

Cullen <in my role as an individual contributor>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 May 2011 08:16:35 +0200

> Given a CoAP URI like coap:1.2.3.4/temp, do I try to connect with DTLS or UDP?

That depends on your security requirements.

This is one of the places where CoAP is almost but not entirely unlike HTTP.

In HTTP, we have exactly two security models: no security, which we map to http://, and security based on server certificates with a somewhat volatile but well-known set of roots and TLS, which we map to https://

This model already breaks in practice with client certificates -- these require lots of local configuration in the client that supplement the information in the URI, which is one of the reasons client certificates are rarely used.

Where https:// is used with a different security model than the usual global set of roots, this requires more configuration (often on both sides).

In CoAP, we have more ways to do security, and in particular more security models (it is indeed rather unlikely that the usual global set of roots model will be useful for a constrained device).

So how do we hope to encode the desired selection of security parameters in the URI?  Having two schemes (a la coap/coaps) is not going to cut it here.  Even if I know that I should be using DTLS, which PSK identity do I choose?  As of today, this requires local configuration.  I trust that, over time, we will come up with extensions to the URI model that will relieve us of some of this need -- but some configuration will always be required for security.

A related issue is the indication of the port number.

In HTTP, http:// implies 80 and https:// implies 443, unless the port number is explicitly given.
These are completely separate resource spaces, i.e. http://a/foo is completely unrelated to https://a/foo (even though it is often a good idea to populate the spaces in parallel).

In CoAP, a single resource may be accessible using multiple security models.  If you don't want to multiplex all those protocols on one port, you would need to indicate the set of ports, one choice per security protocol, in the URI.  This hasn't been done before.

Gruesse, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 5 May 2011 12:46:08 -0600

Configuration is fine for a private network but CoAP is being designed to also be used on the internet and assuming that every node knows about the configuration of every other node does not an assumption I want to make. I'd like to see it such we have a reasonable algorithm for resolving an URL.  I'm fine with also supporting configuration for other types of deployments - obviously private networks are also a huge use case for CoAP - but I'm mostly concerned with the internet case. 

> This model already breaks in practice with client certificates -- these require lots of local configuration in the client that supplement the information in the URI, which is one of the reasons cli…

we disagree here but probably not really relevant to current discussion.

> In CoAP, we have more ways to do security, and in particular more security models (it is indeed rather unlikely that the usual global set of roots model will be useful for a constrained device).

Well this is still a ways from nailed down but I would hope that NoSec and Certificate mode deployments were usable in a internet context while SharedKey and MultKey are restrict more or less by definition. Note the resolution approach for Shared / Mult Key / certificate is pretty easy if you know you are not doing NoSec. If you have a Shared or MultiKey configured to the destination, you use it, otherwise you use the Certificate. TLS is already good at negotiating all this sort of stuff. The questions is how you know if you are in the UDP mode or a mode that use DTLS. Having a coap & coaps scheme is probably the obvious way to do this given we can't use DNS SRV. It nicely mirrors HTTP, is easy to understand and I can't see any reason it would not work. We could do with other ways too. 

> A related issue is the indication of the port number.

I view this as not related - even if we had two schemes, we could given the different or the same default port numbers. 

> These are completely separate resource spaces, i.e. http://a/foo is completely unrelated to https://a/foo (even though it is often a good idea to populate the spaces in parallel).

Not sure where you are going - here... clearly the resource returned can be different in CoAP depending on any characteristic of the request including who made it, how it was authenticated, of if it was over DTLS or not. 

> In CoAP, a single resource may be accessible using multiple security models.  If you don't want to multiplex all those protocols on one port, you would need to indicate the set of ports, one choice…

Cullen <in my individual contributor role>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 17:16:11 +0100

Hi Carsten,

Comments below, bracketed by <RCC></RCC>

Robert

> This model already breaks in practice with client certificates -- these require lots of local configuration in the client that supplement the information in the URI, which is one of the reasons cli…
<RCC>The mapping of https:// is to distinguish HTTP/TLS, i.e. the client 
will initiate with a Client Hello. It has nothing to do with the 
credentials used, which is determined by the TLS handshake (and further 
if two-factor auth. is needed)</RCC>
> Where https:// is used with a different security model than the usual global set of roots, this requires more configuration (often on both sides).
<RCC>Indeed, but this is orthogonal to the transport protocol</RCC>
> So how do we hope to encode the desired selection of security parameters in the URI?  Having two schemes (a la coap/coaps) is not going to cut it here.
<RCC>Why not?</RCC>

>    Even if I know that I should be using DTLS, which PSK identity do I choose?
<RCC>This is negotiated as part of the TLS handshake</RCC>
>    As of today, this requires local configuration.  I trust that, over time, we will come up with extensions to the URI model that will relieve us of some of this need -- but some configuration will always be required for security.
<RCC>I don't think it will be necessary as it can be handled in the TLS 
handshake</RCC>
> These are completely separate resource spaces, i.e. http://a/foo is completely unrelated to https://a/foo (even though it is often a good idea to populate the spaces in parallel).
<RCC>I disagree. They are effectively different front ends to the same 
underlying resource. They will typically go through different access 
control to the resource.</RCC>
> In CoAP, a single resource may be accessible using multiple security models.  If you don't want to multiplex all those protocols on one port, you would need to indicate the set of ports, one choice…
<RCC>The negotiation would be done as part of the TLS handshake. No 
different to HTTP access in my opinion</RCC>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>