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

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2011 18:09:52 -0800

I just read this document.

Overall, I don't understand the motivation for this document. The
Introduction implies that it's more efficient than DTLS with shared
keys, but I don't see any reason to expect that that is in fact the
case. Moreover, given the difficulty of designing correct
cryptographic protocols, you would need a very large efficiency gain
to justify this.

If I'm understanding this document correctly, the described
protocol is also subject to attacks which should be
prevented by a properly designed cryptographic protocol:

* I don't understand how this document prevents complete replay
  attacks. Given the short Context-ID, repeated contexts
  are inevitable, with the result that from the server's
  perspective it is not possible to distinguish complete
  replays of old connections and new connections, as long
  as the server has forgotten or timed out the Context-ID
  being replayed. Moreover, if the client times out and replays
  a Contex-ID, he too is subject to replay attacks.
  The conventional defense against this attack is for both sides
  to supply a longish nonce which is mixed into the long-term
  key to produce a traffic key.

* The handshake does not appear to be secure against downgrade
  attacks in which the attacker removes weak cipher suites
  from the client's CryptoInitiate in order to force the
  client and server to choose the weakest common cipher.
  The standard defense here is to have a strong MAC over the
  entire handshake based on the shared key. (D/TLS calls
  this the Finished).

Additionally, the anti-replay mechanism described in S 2.3
is very inconvenient, because it requires each side to memorize
every nonce in every valid context. The standard mechanism
here is to use sequence numbers and an anti-replay window.
Also, I wonder if there is a reflection attack here.

Given these issues, it's not clear to me why one would wish
to take on this document rather than use a well understood
protocol.

-Ekr

---

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

> I just read this document.

Thank you.

>  key to produce a traffic key.

We do have a nonce in the I-D. Please see Section 2.3.1. 

>  entire handshake based on the shared key. (D/TLS calls

You are right. Will do in rev.

> here is to use sequence numbers and an anti-replay window.

Right. Will do.

> Also, I wonder if there is a reflection attack here.

Let me think...

> to take on this document rather than use a well understood

I'm hoping our presentation today will shed light to that. We can take it from there…

Thanks.

Alper

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2011 18:31:42 -0800

> We do have a nonce in the I-D. Please see Section 2.3.1.

That nonce is a per-message nonce, not a per-association nonce.
Unless you store that nonce forever, I believe you have a
whole-association replay problem.

>> Also, I wonder if there is a reflection attack here.

At this point aren't we just redesigning DTLS shared key mode?

-Ekr

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 Nov 2011 05:08:39 +0200

> whole-association replay problem.

Got it. When we add integrity protection to the CryptoInitiate, we'll handle that as you suggested.

> At this point aren't we just redesigning DTLS shared key mode?

Obviously PSK mode in DTLS, IPsec, XML-ENC/DSIG, JOSE, Mobile IP, L2 ciphering, and anything of that sort have these common. And the same applies to this method. These should be common unless we are inventing some new crypto, or not using the crypto the right way. Neither is meant to be the case. We are fixing up the issues you are identifying. 

The essential difference among those protocols is the "layer" they operate on.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2011 19:30:25 -0800

> Obviously PSK mode in DTLS, IPsec, XML-ENC/DSIG, JOSE, Mobile IP, L2 ciphering, and anything of that sort have these common. And the same applies to this method. These should be common unless we ar…

Yes, but the point is that it's *hard* to design a new protocol of
this kind that
doesn't have a bunch of security issues, as evidenced by the number of
things i found in a cursory inspection. Thus, the barrier to arguing that
you need a new protocol is fairly high.

> The essential difference among those protocols is the "layer" they operate on.

Yes but I have yet to hear a convincing argument for why that is a significant
improvement in this case.

-Ekr

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 Nov 2011 05:46:36 +0200

Obviously we must get the crypto right (I'd have been surprised if we got it 100% right in version-00).

But I think the primary question on the table is this: 

	What is(are) the right layer(s) we shall define or rely on a security solution for CoAP.

One can rely on security at one or more of the following layers:

Physical
Link-layer 
Network (e.g., IPsec)
Transport (e.g., DTLS)
CoAP-layer (this proposal)
CoAP-payload media-layer (XML, JSON, etc.)
Application layer

Solutions at each layer above have its pros and cons. 
We talk about such things all the time in IETF. We end up following different approaches most of the time. I was in PCP earlier, and now I see they are relying on Phy and Link-layer security. 

I'm not saying we shall always have solutions at every layer for any protocol. It goes case-by-case, and we have a case at hand.

> improvement in this case.

Can we dive into that during/after my presentation? My detailed answer is there.

Alper

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2011 19:51:54 -0800

> I'm not saying we shall always have solutions at every layer for any protocol. It goes case-by-case, and we have a case at hand.

Yes, we do, but these decisions aren't made in a vacuum.

One of the important constraints in these discussions is what
protocols already exist. In this case, we have an existing, mature protocol
being compared against a new protocol with extremely similar security
properties (i.e., one that is not gaining substantial superior security
properties via upper layer integration), with the only real arguments
for the new protocol being efficiency. If you were actually making
use of the fact that you were integrating it into CoAP, I might feel
differently.

> Can we dive into that during/after my presentation? My detailed answer is there.

OK. As a preview, if the argument you're planning to offer is based on
wire format
compactness (which appears to be what your slides say) I find that profoundly
unconvincing.

-Ekr

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 Nov 2011 06:01:57 +0200

> use of the fact that you were integrating it into CoAP, I might feel

I'm integrating into CoAP, and highlighting the benefits. See Slide 5. All those different uses are possible only if we use a CoAP-layer security. Cannot do the same with IPsec/DTLS.

> compactness (which appears to be what your slides say) I find that profoundly

Over-the-wire byte savings and round-trips saving are there. But that's not what excites me (maybe some gets excited, as it seems like we are after byte/rtt savings in this WG). Slide 5 is what I find more appealing.

Alper

---

From: Robert Cragie <[email-masked]>
Date: Fri, 18 Nov 2011 05:07:05 +0000

I think there are two questions to consider here:

1) Do we need CoAP-layer security, i.e. where we distinguish the 
header/payload(s) at the CoAP layer and provide corresponding message 
protection?
2) If so, is the mechanism described in the document adequate?

For (1), I think there may be some merits to specifying, as Alper points 
out on slide 5. Also, in my experience so far, it seems the IETF 
generally likes to have a protocol message security solution whether it 
ends up getting used or not to meet the general security requirements 
for a protocol, for example for RPL options.
For (2), the solution proposed does seem lightweight and therefore open 
to the issues already raised by others.

Some specific other comments:

* The CryptoInitiate needs to be more conversational and establish a 
more distinct session, along the lines of (D)TLS/IKEv2/HIP BEX/DEX
* Use of the pre-shared key for session establishment and message 
protection is overloading the use of the key. A separate session key 
should be established. Or is the intent that the initial pre-shared key 
be different for every session anyway? If so, then there will need to be 
an additional KMP anyway to establish this key, which would resemble 
(D)TLS/IKEv2 no doubt, so we seem to be back to square one.

Robert

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2011 21:10:04 -0800

On Thu, Nov 17, 2011 at 9:07 PM, Robert Cragie
<[email-masked]> wrote:
> For (1), I think there may be some merits to specifying, as Alper points out
> on slide 5. Also, in my experience so far, it seems the IETF generally likes
> to have a protocol message security solution whether it ends up getting used
> or not to meet the general security requirements for a protocol, for example
> for RPL options.

That hasn't been my experience. The vast majority of the protocols I'm familiar
with are basically just being used with some channel-level security mechansm
(typically TLS).

-Ekr

---

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

Hi Robert, 

If you want an application layer security solution then why don't you use use the work JOSE is doing by protecting some application specific elements using JSON object signing and encryption? 

Ciao
Hannes

On Nov 18, 2011, at 6:07 AM, Robert Cragie wrote:

> 1) Do we need CoAP-layer security, i.e. where we distinguish the header/payload(s) at the CoAP layer and provide corresponding message protection?
> For (1), I think there may be some merits to specifying, as Alper points out on slide 5. Also, in my experience so far, it seems the IETF generally likes to have a protocol message security solution whether it ends up getting used or not to meet the general security requirements for a protocol, for example for RPL options.
> For (2), the solution proposed does seem lightweight and therefore open to the issues already raised by others.
> 
> * The CryptoInitiate needs to be more conversational and establish a more distinct session, along the lines of (D)TLS/IKEv2/HIP BEX/DEX
> * Use of the pre-shared key for session establishment and message protection is overloading the use of the key. A separate session key should be established. Or is the intent that the initial pre-shared key be different for every session anyway? If so, then there will need to be an additional KMP anyway to establish this key, which would resemble (D)TLS/IKEv2 no doubt, so we seem to be back to square one.
> 
> Robert
>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 18 Nov 2011 05:19:43 +0000

I remember the discussion regarding RPL and there still ended up being 
some relatively arcane mechanism for protecting RPL packets. IIRC the 
argument was that it wasn't sufficient to say that the RPL packets would 
be protected at Layer 2 and that using IPSec (the obvious solution) was 
too heavyweight. So maybe the IETFs encroachment into trying to optimise 
for bytes on the wire and device complexity is spawning these additional 
security mechanisms. I personally agree with you - I think it makes far 
more sense to use DTLS.

Robert