Subject: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck

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

The draft requires CoAP to be both a layer bellow DTLS and a layer above it. This type of layer violation will really complicate things in the future. For example, imagine that we were trying to do CoAP over DTLS over DCCP over UDP. Where does the wacky COAP shim go, below DTLS or above DCCP. If an underlying hardware implication provided DTLS offload over UDP, it could not be used because CoAP has to be inserted in between DTLS and UDP. If we wanted to tie the DTLS compression to the underling link layer hardware compression it would not work. If something clever was happing between the DTLS over HIP and the HIP layer, this might confuse it. Some layer violation are well worth it, this is not one of them. As far as I can tell there is pretty much no reason for doing this. The obvious thing to do is be the same as HTTP and use two ports one for DTLS and one for CoAP with DTLS. 

I want to put particular focus on the point that most people that build large scale systems that use TLS fast crypto hardware to terminate the TLS at the aggregation points then pass the data on to the servers behind that. Some vendors do have support for DTLS acceleration as well as TLS but asking for a custom hardware support for CoAP is pretty to hard to ask for until the market for this is all a lot larger than it currently is. 

Lots of protocol look like protocol X on top of DTLS on top of UDP. Asking for X on top of DTLS on top of X on top UDP is not reasonable. 

Cullen <in my role as an individual contributor>

PS - Oh, and I'd also like to make the point and that many CoAP implementations will be using dynamically linked library to get DTLS so the CoAP application calling the library may not even be able to tell if the DTLS implementation uses code points other than the ones defined in DTLS 1.2. So implications like this have to check every packet the DTLS stack sends to the UDP stack and see if it needs escaping. It's not a future problem, it's a "now" problem.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 May 2011 07:54:55 +0200

I don't get it.

You can use any layering you want.

All section 7.3 does is ensure DTLS (and STUN) and CoAP *can* coexist on a single port if you want to.

If your implementation techniques make you not want this, don't do that then.

Yes, the problems with, e.g., OpenSSL are real.  But in our implementations so far we need to insert a BIO shim there anyway because OpenSSL makes assumptions about DTLS that aren't quite right.

I read this as a rant that we should get a second port allocation for CoAP over DTLS over UDP.
I'm certainly fine with that.

(This issue is, of course, related to the question on how to specify security in a URI. See there.)

Gruesse, Carsten

---

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

> I'm certainly fine with that.

A second port - one for UDP and one for DTLS would certainly solve all my problem with this. I don't see any problem with that choice. And if we do this, the topic of if we need a coaps URL scheme or not seems like a separable problem to me. Just because we have two ports, we still might decide to only have one scheme.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 May 2011 17:51:22 -0700

> All section 7.3 does is ensure DTLS (and STUN) and CoAP *can* coexist on a single port if you want to.

I'm not sure I understand why this is a desirable property. We've done
pretty well in the HTTP case
by simply using separate ports and it's not clear to me why on ought
to deviate from that. I realize
that some people are concerned about port depletion, but refusing a
second port isn't any kind
of IETF policy and this seems like a case where it fairly obviously
makes a difference.

With that said, if you *do* want to demux on the same port, the
particular mechanism described
here doesn't seem that great. If you're doing DTLS (or pretty much any
crypto protocol) you've
already accepted a fair amount of overhead, minimally the record
framing, record sequence number,
and framing, so the additional byte doesn't seem to have that big an
impact (< 6% increase in packet
size) when compared to the complexity of conditionally escaping.
Moreover, it seems unwise to
escape STUN since it is likely that future NATs will want to do stuff
with it. My suggestion would be:

1. Use STUN as-is.
2. Use a leading framing byte to distinguish DTLS and CoAP from STUN.
If you're really worried
about compactiness, then pick only a single value to distinguish DTLS
(e.g., 0xffffffff) and use all
the remaining values to give you a little more room in the rest of the packet.

> Yes, the problems with, e.g., OpenSSL are real.  But in our implementations so far we need to insert a BIO shim there anyway because OpenSSL makes assumptions about DTLS that aren't quite right.

I'd be interested in hearing more about this, perhaps offline, so I
can get the right fixes
into OpenSSL.

-Ekr

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 03:24:19 +0200

> 1. Use STUN as-is.

Yep, we are doing that.
(The escaping stuff is insurance for a case that is rather unlikely.  We could take it out.)

What is the status about STUN coexisting with DTLS?

> about compactiness,

(Yes, we are.)

> then pick only a single value to distinguish DTLS
> (e.g., 0xffffffff)

(That would be a bit long.)

> and use all

Sure, we could do that.  It would mean spending another byte for all DTLS packets.
More importantly, it also means DTLS packets no longer look like DTLS packets, which complicates debugging.

I would like to learn more about your plans to expand the DTLS ContentType space.
This hasn't changed since 1996.  Of course, it could, next month.
Again, the escaping stuff is insurance for this case.  We could take it out.

Gruesse, Carsten

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 May 2011 00:49:42 -0700

> What is the status about STUN coexisting with DTLS?

As far as I know, there's no problem, since the leading bytes plus cookies make
collisions very unlikely.

> (That would be a bit long.)

Sorry, brain failure. 0xff

> Sure, we could do that.  It would mean spending another byte for all DTLS packets.

Right. My argument is that that's not that big a deal because it only
increases space
by ~5%.

> More importantly, it also means DTLS packets no longer look like DTLS packets, which complicates debugging.

Yes, I agree that that's suboptimal. That's why I prefer separate ports...
The material you're quoting above is just some other thoughts for dealing with
the same port if people insist.

> Again, the escaping stuff is insurance for this case.  We could take it out.

I don't think there are any immediate plans to do so--though note that
http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-01
does contemplate one addition. And I would assume that we intend to
assign the content-types towards the bottom of the range first. That said,
I don't think TLS-WG has by any means decided to commit to not
assigning a bunch more types.

Bes,t
-Ekr

---

From: Robert Cragie <[email-masked]>
Date: Tue, 10 May 2011 14:55:52 +0100

I have never seen what the issue is with using two ports like HTTPS:

    * One port for CoAP over UDP
    * One port for CoAP over DTLS over UDP

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 06/05/2011 8:49 AM, Eric Rescorla wrote:
> On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann<[email-masked]>  wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Thomas Herbst <[email-masked]>
Date: Wed, 11 May 2011 11:28:30 -0700

+1

From: Robert Cragie <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 10 May 2011 06:55:52 -0700
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com<http://www.gridmerge.com/>

On Thu, May 5, 2011 at 6:24 PM, Carsten Bormann <[email-masked]><mailto:[email-masked]> wrote:

1. Use STUN as-is.

Yep, we are doing that.

(Yes, we are.)

and use all

Bes,t
-Ekr
_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Fri, 13 May 2011 17:25:21 +0300

This subject line is really amusing :-) 

No really, what is being suggested here is two things:

1. Separate ports for CoAP (NoSec mode) and DTLS/CoAP (Anything != NoSec mode)
2. A separate coaps:// scheme to indicate DTLS/CoAP

Originally, the single scheme and port approach really did make sense as our security modes were pretty varied and could be accomplished by *either IPsec or DTLS*. In Prague we made an important decision to bind DTLS support strongly into CoAP. After this change, I don't see any problem going with the separate port and scheme approach if that is what the WG wants (definitely seeing support for this change). Besides, I could remove Section 7.3 all together :-)

The caveat though as Carsten pointed out, is that coaps:// will require more configuration than https:// as we have more possible modes. This would need to be discussed in the security section. I guess coaps:// would need to assume some defaults unless otherwise configured. 

Is there any strong objection to going with this separate port and scheme model? 

Zach

On May 11, 2011, at 9:28 PM, Thomas Herbst wrote:

> +1
> 
> From: Robert Cragie <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> 	• One port for CoAP over UDP
> 	• One port for CoAP over DTLS over UDP
> 
> Robert
> http://www.gridmerge.com
>> [email-masked]://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

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

Hi Zach,

Comments inline...

Robert

> Originally, the single scheme and port approach really did make sense as our security modes were pretty varied and could be accomplished by *either IPsec or DTLS*. In Prague we made an important de…
<RCC>There is a difference. If you are using IPsec, it would be 
CoAP-over-UDP-over-IPsec. So it makes sense to use the same port as 
CoAP-over-UDP-over-IP. However, using DTLS it would be 
CoAP-over-DTLS-over-UDP. As TLS records encapsulate the CoAP, the 
ability to distinguish on the first byte gets lost, hence the suggestion 
to use a separate port.</RCC>

> The caveat though as Carsten pointed out, is that coaps:// will require more configuration than https:// as we have more possible modes. This would need to be discussed in the security section. I g…
<RCC>I don't agree. I have responded separately to Carten's e-mail</RCC>

---

From: Zach Shelby <[email-masked]>
Date: Sun, 15 May 2011 22:18:06 +0300

On May 13, 2011, at 7:17 PM, Robert Cragie wrote:

> <RCC>There is a difference. If you are using IPsec, it would be CoAP-over-UDP-over-IPsec. So it makes sense to use the same port as CoAP-over-UDP-over-IP. However, using DTLS it would be CoAP-over-DTLS-over-UDP. As TLS records encapsulate the CoAP, the ability to distinguish on the first byte gets lost, hence the suggestion to use a separate port.</RCC>

Yes, this is what I was trying to say. Now that -06 is clearer about the binding to DTLS, the separate ports and scheme works.

> <RCC>I don't agree. I have responded separately to Carten's e-mail</RCC>

Will follow that. For me this is really just an editorial issue in the security section regarding how much needs to be said about the configuration needed to make use of a coaps:// scheme. In other words, how to make SharedKey, MultiKey and Certificate mode work out of the box. You seem to be saying that TLS will just negotiate this.

Zach

---

From: Robert Cragie <[email-masked]>
Date: Mon, 16 May 2011 08:40:13 +0100

> Will follow that. For me this is really just an editorial issue in the security section regarding how much needs to be said about the configuration needed to make use of a coaps:// scheme. In other…
<RCC>If you base those modes on TLS cipher suites, then they can be 
negotiated as part of the TLS handshake. Let me take a closer look 
too.</RCC>

Robert