Re: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-08.txt

["Kumar, Sandeep" <[e-mail]>]

Hi Mike

See inline

From: Michael StJohns [mailto:[e-mail]]
Sent: Tuesday, July 08, 2014 5:24 PM
To: Kumar, Sandeep; [e-mail]
Subject: Re: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-08.txt

On 7/8/2014 8:26 AM, Kumar, Sandeep wrote:

Hi Mike



See inline



> -----Original Message-----

> From: dtls-iot [mailto:[e-mail]] On Behalf Of Michael

> StJohns

>

> In the interim,

> https://datatracker.ietf.org/doc/draft-kumar-dice-groupcomm-security/

> has been submitted.  That document shares a lot of the same boilerplate text

> as this document and I thought it was headed in the direction of defining

> public key mechanisms at the COAP layer rather than something at the DTLS

> layer, but it seems to have mostly restated this document with a few

> paragraphs on why public key is too expensive and *maybe* moving the

> symmetric key secure multicast problem to the COAP layer (but even that's

> unclear).

>

[SK] I do not understand what you are referring to but draft-kumar-dice-groupcomm-security

clearly includes the public key options. The SIG field in Figure 2 and Figure 3 are the

public key signatures. This is exactly what we had discussed offline in London on how such a solution would look like.

The symmetric key MAC was also mentioned at the mike in London as being useful for DoS protection.

Confidentiality does not even come into picture if you choose a ciphersuite which has no encryption

Hi Sandeep -

I probably was a bit too harsh on my comments, but I got there from:
[SK] Indeed I would prefer if there were concrete comments which are constructive

o Section 4.3 which is basically arguing that PK is too expensive and complex.
[SK] Section 4.3 says only this about PK "This draft use more computationally
   intensive operations based on PKC for each and every individual
   message.  This can be quite demanding on many cheap IoT devices which
   have strong memory and power constraints."
Do you find this statement wrong!?

o Section 4.2 which suggests that PK might be better done as part of DTLS (shim layer).

[SK]I don't see where I suggest the shim layer to be a better solution here.
I just want to make clear that if changes to CoAP are not feasible then the same operations can be performed in a shim layer.
It need not be the DTLS (but not because of a technical reason but because Ekr does not prefer it) and can be completely different (and also call it completely different )

o Section 3.2 which is mostly what you need to do symmetric key multicast only slightly modified for PK.
[SK] I really don't see where you are going here. This is a solution which needs PK to enable source authenticity.
The SK is for other reasons and we can debate what additional value it brings in constrained environments. As already explained in the draft, the SK based MAC would enable a first level of basic checking if the message originated within the group before starting the more expensive PK verification. Yes the key may be stolen easily, but then the receivers see a strange MAC verification success and a PK verification fail to raise an alarm and get the MAC key changed. Does it provide additional value if there was no MAC? Yes since receivers would always perform a DoS PK verification compared to a smaller time window (from MAC key compromise and then getting changed). This can mean a lot for devices that need to run on batteries for years. Why not use link layer security, read below.

o Section 6. which is all about the issues with symmetric key confidentiality rather than discussing PK source and integrity.

[SK] Yes because SK has more issues and I still need to detail out PK design to make any concrete list of issues here. Note that this is a first straw-man draft for discussion as was indicated in IETF London.

Overall I think I saw this document somewhere before without any of the PK stuff in it, but I can't place it.  And this document really does share a lot in common with draft-keoh....
[SK] draft-keoh contains a lot of valuable feedback from others both within IETF and outside. Even things related to proxy and how responses are to be handled have similarities independent of the underlying security primitive. I would rather take those feedback than start from blank.

What I was hoping for based on our discussions was a draft that described only PK source auth  and integrity at the CoAP level without mixing in any of the symmetric key issues.    And that was actually an implementation spec or closer to one (e.g. here's the actual format for how you encapsulate signatures with CoAP and here's the backwards compatibility issues), and here's what gets signed.  And here's how it gets verified.  And here's how it gets placed in a groupcomm message.
[SK] I am afraid but my recollection of the discussion was that PK needs to performed on the appropriate fields and added at the appropriate location to enable source authenticity. And in any case this is an individual contribution to the discussion, it will be up to the WG to decide if SK is needed. I will strongly support keeping it in.

Finally, a PK signed CoAP message shouldn't have any special handling considerations - it gets sent either unicast or multicast like any other CoAP message.  The receiving node makes a decision on whether to act on the contents of the message based on the identity of the sender and whether the message verifies.
[SK]Yes sounds straightforward on paper, but I prefer that the more experienced CoAP folks look at it and help detail the solution. This is of course depending on how the WG wants to proceed.

With respect to the symmetric key multicast stuff - it continues to be a red herring.  If you provide link layer security for your IOT mesh, (which can be done as a two-party symmetric key system), you get as much or more privacy protection that you get if you try and do symmetric key at the multicast level.  The DOS protection you mention is subject to the exact same set of attacks mentioned before - ANYONE that has the multicast key can send verified traffic, which means that even one weak link (e.g. your lightbulb being hacked - and it will) makes that DOS protection moot.
[SK] I had shown the use case in more detail in IETF London where I clearly said that the solution was meant to work with group members distributed in different link layers (wireless or wired) but running IP. In that case DoS protection at a higher layer is required unless changing in-between router's behavior to start joining every group and doing all kinds of verification.

Regards
Sandeep




________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.