Subject: [core] draft-yegin-coap-security-options-00

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Nov 2011 05:46:48 +0100

I also read this document. 

I do not quite understand why DTLS does not work for you. You are essentially defining another authentication and key exchange protocol above UDP. It claims to be an "efficient alternative" to DTLS but does not explain why. Designing new cryptographic mechanisms from scratch is time consuming and difficult. The document is missing a lot of details of what would be needed to describe such a protocol!

Ciao
Hannes

---

From: Zach Shelby <[email-masked]>
Date: Fri, 18 Nov 2011 13:19:42 +0800

I want to explain my intensions by co-authoring this with Alper. 

Talking to people over the last years while starting and during the CoRE WG, the stark reality is that there is a huge gap between what M2M industry people need (want?) and what the IETF has to offer in terms of security. 

Thanks to lots of cross-area cooperation and helpful security people, this is getting better. For example recent work on more efficient ciphers, the work on raw public keys, or object security work in JOSE. Our draft is a bit controversial on purpose as we want to stimulate discussion. 
	- Is there interest and possible need for this class of security in CoRE? 
	- Are there ways that DTLS could be made better for simple PSK applications? 
	- How do we fill the gap between NoSec and PreSharedKey modes? 

What I am hearing so far, is that security people think it is not a good idea to design a new security protocol. Personally, I agree. 

However, does that mean that we have volunteers to help make DTLS even more applicable to M2M applications? TinyDTLS? If that is what we are stuck with for all constrained application environments, it might be the long-term direction we need to take. 

Zach

On Nov 18, 2011, at 12:46 PM, Hannes Tschofenig wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
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: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2011 21:37:11 -0800

> However, does that mean that we have volunteers to help make DTLS even more applicable to M2M applications? TinyDTLS? If that is what we are stuck with for all constrained application environments,…

I'm certainly enthusiastic about trying to make DTLS work better for CoAP.

I think it would be best to start with an enumeration of the (no doubt
many) deficiencies in
DTLS which are affecting you. Some of them may be fixable within DTLS,
some may require a
different style of protocol, and some may be open research questions.
But we won't know
till we have a gap analysis...

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Nov 2011 06:50:11 +0100

Hi Zach, 

I found the slides from the meeting that contained some information about the performance benefits. I will have to look at the details of it a little later. 

I fully understand your need to make security mechanisms fit the smart object space. The problem here is, however, that there are different design goals. 

For example, a design decision you have to make is whether you want an initial authentication and key exchange phase followed by the actual protection of the data traffic (integrity/confidentiality/data-origin authentication). 

The benefit of having these two phases is that you can do the expensive operations at the beginning and then you get to be more efficient later with the data protection itself. Clearly, a solution that does not do the initial phase (as it is the case with, for example, CMS) is from a message point of view much more efficient. If you main goal is to reduce the number of messages then you are clearly able to accomplish it by omitting the initial phase.

In your writeup I actually get the impression that the context setup and context teardown are not complete since they do not offer the main features provided with many other protocols, such as the actually authentication and key establishment (establishment of short term temporary keys). Typically, you want to avoid using your long-term credentials for the per-packet security. 

So, I believe it helps a lot to explain what your main goals are, such as reducing the code size, the number of messages, the per-packet overhead,  the number of cryptographic operations, the number of different cryptographic primitives etc. Typically, these goals will be in conflict with the set of features you want to have. 

Ciao
Hannes

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 18 Nov 2011 14:09:04 +0800

> till we have a gap analysis...

The audio had cut off when Cullen said this, but he asked the authors to
post to the SAAG list about this topic.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Zach Shelby <[email-masked]>
Date: Fri, 18 Nov 2011 22:09:01 +0800

> post to the SAAG list about this topic.

Of course this CoAP security option document needs to be discussed in SAAG as Cullen pointed out. Not in a rush in my opinion.

I like the idea of writing a kind of session security for M2M requirements and gap analysis draft, which could help us in thinking about future DTLS improvements. We can probably find authors to work on that on this list, and submit it to the TLS WG. This should also point out use cases as Hannes suggested. 

From my experience so far, we can live with DTLS PSK or RPK for most of the higher-end M2M applications (like Cellular M2M). So this document would shoot for the other applications in-between where implementers, system designers and other SDOs might be tempted to do something less than secure by themselves if they perceive DTLS as being too heavy or unsuitable for their needs. 

Zach