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

[Michael StJohns <[e-mail]>]

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:

o Section 4.3 which is basically arguing that PK is too expensive and 
complex.

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

o Section 3.2 which is mostly what you need to do symmetric key 
multicast only slightly modified for PK.

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

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....


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.


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.

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.

Mike