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

[Zach Shelby <[e-mail]>]

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 <[e-mail]>
> Reply-To: "[e-mail]" <[e-mail]>
> Date: Tue, 10 May 2011 06:55:52 -0700
> To: "[e-mail]" <[e-mail]>
> Subject: Re: [core] draft-ietf-core-coap-06 The CoAP/DTLS/CoAP Turkey Sandwich layer violation train wreck
> 
> 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
> [phone]
> [phone]
> 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 <[e-mail]>
>>  wrote:
>> 
>>> On May 6, 2011, at 02:51, Eric Rescorla wrote:
>>> 
>>> 
>>>> 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?
>>> 
>> As far as I know, there's no problem, since the leading bytes plus cookies make
>> collisions very unlikely.
>> 
>> 
>> 
>>>> 2. Use a leading framing byte to distinguish DTLS and CoAP from STUN.
>>>> If you're really worried
>>>> about compactiness,
>>>> 
>>> (Yes, we are.)
>>> 
>>> 
>>>> then pick only a single value to distinguish DTLS
>>>> (e.g., 0xffffffff)
>>>> 
>>> (That would be a bit long.)
>>> 
>> Sorry, brain failure. 0xff
>> 
>> 
>> 
>>>> and use all
>>>> the remaining values to give you a little more room in the rest of the packet.
>>>> 
>>> 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.
>> 
>> 
>> 
>>> 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.
>>> 
>> 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
>> _______________________________________________
>> core mailing list
>> 
>> [e-mail]://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> [e-mail]
> https://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: [phone]