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

From: Ari Keranen <[email-masked]>
Date: Wed, 16 Nov 2011 16:15:27 +0800

Hi,

I had a quick read over the draft-yegin-coap-security-options-00 and 
have a few comments.

While it's an interesting idea, I'm not really convinced of the comment 
in the draft that "a solution defined within the same layer as the base 
specification would provide an efficient alternative to DTLS and IPsec 
in terms of crypto context setup, packet size, and implementation 
overhead." Where do you base this assumption? It would be nice to see 
some numbers or even estimates (not necessarily on the draft).

And we do already have fairly well working end-to-end security 
mechanisms (DTLS, IPsec) and even with light-weight keying (Tero's 
example of minimalistic IKEv2, HIP DEX). Considering that security is 
really hard to get right, I'd definitely recommend using something that 
already exists and has been widely reviewed. That said, your solution 
does have a bit different approach (can encrypt only parts), but how 
much benefits does that give (you do crypto over X bytes instead of X+6 
bytes?), I'm not that sure of.

Also, I'm a bit concerned about the fact that key management is out of 
scope for the document. After all, that's often the hard part in 
security protocols.

I'd need to have a closer look at this, but I think this protocol 
proposal could be also vulnerable to downgrade-attacks.

Anyhow, these are just some examples that I know, e.g., with HIP has 
been thought a lot, and I'd assume also IKE and DTLS has protection 
against. Yes, you could re-invent all that on top of CoAP, but in that 
case, why not just use something that already exists?

Some specific comments:

       - Context ID: One-octet unsigned integer value.  Value 0 is
       reserved to indicate invalid context ID, values 1-255 are valid.

This limits the amount of contexts to 255; how about e.g., an 
aggregating/gateway node taking care of more than 255 sensor nodes?

I found the use of strings as key and crypto algo identifiers a bit 
strange. Why not use, say, integer values which map to different algos 
and have an IANA registry for that?

Cheers,
Ari

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Nov 2011 09:07:21 +0200

Hi Ari,

Thank you for the feedback.

Please see below for my feedback.

On Nov 16, 2011, at 10:15 AM, Ari Keranen wrote:

> Hi,
> 
> I had a quick read over the draft-yegin-coap-security-options-00 and have a few comments.
> 
> While it's an interesting idea, I'm not really convinced of the comment in the draft that "a solution defined within the same layer as the base specification would provide an efficient alternative to DTLS and IPsec in terms of crypto context setup, packet size, and implementation overhead." Where do you base this assumption? It would be nice to see some numbers or even estimates (not necessarily on the draft).
> 

Let me work out some numbers and put on the slides.

> And we do already have fairly well working end-to-end security mechanisms (DTLS, IPsec) and even with light-weight keying (Tero's example of minimalistic IKEv2, HIP DEX). Considering that security is really hard to get right, I'd definitely recommend using something that already exists and has been widely reviewed. That said, your solution does have a bit different approach (can encrypt only parts), but how much benefits does that give (you do crypto over X bytes instead of X+6 bytes?), I'm not that sure of.
> 

DTLS and IPsec are available and solid. They provide channel security. But that does not boil down to never developing/using a higher-layer security. XML security and now JOSE WG are good counter examples of that. 

Even in IETF for Mobile IPv4 we used a solution similar to coap-security. In fact, that experience suggested me this question: How come we are not doing it the same on CoAP. I asked that question on the mailing list, no response. So, I did the exercise of developing "a" solution, and now collecting feedback :-)

Then for Mobile IPv6 we did what you recommended with IPsec, and that created problems… 

> Also, I'm a bit concerned about the fact that key management is out of scope for the document. After all, that's often the hard part in security protocols.
> 

Yes, it's a hard problem. But it's a separate problem. 
"Key management" and "using the generated key to secure a protocol" are typically separate mechanisms. One can  come up with an integrated solution. Integration is not ideal, but maybe useful. (Not sure if this is what your proposal is suggesting…) 

> I'd need to have a closer look at this, but I think this protocol proposal could be also vulnerable to downgrade-attacks.
> 
> Anyhow, these are just some examples that I know, e.g., with HIP has been thought a lot, and I'd assume also IKE and DTLS has protection against. Yes, you could re-invent all that on top of CoAP, but in that case, why not just use something that already exists?
> 
> Some specific comments:
> 
> This limits the amount of contexts to 255; how about e.g., an aggregating/gateway node taking care of more than 255 sensor nodes?
> 

255 contexts between two end-points. Each end-point can have so many context with each other end point it is communicating with. So, this ID space is per pair of devices.

> I found the use of strings as key and crypto algo identifiers a bit strange. Why not use, say, integer values which map to different algos and have an IANA registry for that?
> 

Algo identifiers is one-octet integer.

Key name is a string, similar to what XML and TLS does. (I think string is more flexible in defining key names than an integer is).

Thank you.

Alper

---

From: René Hummen <[email-masked]>
Date: Thu, 17 Nov 2011 18:43:00 +0100

Hi Alper,

> DTLS and IPsec are available and solid. They provide channel security. But that does not boil down to never developing/using a higher-layer security. XML security and now JOSE WG are good counter e…

As far as I am aware, XML security does object security whereas DTLS and IPsec do transport security. These are two different things and require the standardization of distinct security mechanisms. 

> Then for Mobile IPv6 we did what you recommended with IPsec, and that created problems… 

In my opinion, specifying a new security protocol for smart objects impedes the interoperability story between smart objects and Internet hosts as achieved by 6LowPAN (adaptation layer) and CoAP/HTTP (proxy). Right now, Internet hosts implement TLS/DTLS and IPsec. Do we expect them to support a special CoAP security protocol as well? 

> "Key management" and "using the generated key to secure a protocol" are typically separate mechanisms. One can  come up with an integrated solution. Integration is not ideal, but maybe useful. (Not…

I agree with Ari on this one. Can you elaborate on what you mean by "integration is not ideal"?

BR
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 Nov 2011 03:29:04 +0200

Hi Rene,

> As far as I am aware, XML security does object security whereas DTLS and IPsec do transport security. These are two different things and require the standardization of distinct security mechanisms. 

Right. the point is, if TLS/IPsec were enough, then we'd not be talking about those others at all, like Ari was suggesting.

> In my opinion, specifying a new security protocol for smart objects impedes the interoperability story between smart objects and Internet hosts as achieved by 6LowPAN (adaptation layer) and CoAP/HT…

Most of the time the devices won't be supporting all of them. And indeed adding one more to the toolbox works against the interop, and shall only be done if it is beneficial. 

> I agree with Ari on this one. Can you elaborate on what you mean by "integration is not ideal"?

Integrated means developing one solution (or a tightly-bound double-sided solution) that handles both key management and key use. I was responding to Ari about why we are solving one of the problems and not the other. Ours is equivalent to providing a DTLS-PSK solution but not describing how the PSK got there.

Alper

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