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

[Michael StJohns <[e-mail]>]

Hi Sandeep -

Also inline.

On 7/10/2014 4:11 AM, Kumar, Sandeep wrote:
>
> 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/*
>



I listed a specific and concrete conclusion I'd come to about the 
document - to wit:

> it seems to have mostly restated this [draft-keoh-dice-multicast-security] 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

I'm unconvinced that was an incorrect conclusion.

It's difficult to make substantive and constructive comments when there 
are no substantive changes.  To put it another way, it's somewhat 
useless to comment on which colors the walls should be painted if the 
building is built on a sand foundation on a beach just in time for 
hurricane season.   In the current case - your sand foundation is 
symmetric key multicast security and what I'm looking for is the design 
criteria for a public key break water or drain system or nice new 
elevated foundation.

>
> 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!? /*
>
No, I find it incomplete and one-sided.

For example:  "On the other hand, PKC actually meets the security needs 
of the given use cases and does not require a secure processing element 
in each node for protection against single key compromise attacks.  The 
higher [processing demands of asymmetric key cryptography can be 
somewhat mitigated by choosing an algorithm suite with a strength 
appropriate for the application - e.g. something smaller than EC P-256 
curves".

Section 4.3 was entitled "Comparison between the solutions" and instead 
provided only half of the discussion.  So I stand on the statement I made.

Also "this can be quite demanding..." is a blanket conclusion without 
evidence or constraint.  How small a device?  Powered, unpowered?  Other 
assumptions?  Acceptable latency to sign/verify? Some real data plus 
analysis would be useful.


>
> 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 )/*
>
The first sentence in 4.2 is "In this solution, the security of group 
message closely matches the abstract model..." - with the implication 
that 4.2 is the best matching solution.  Also, the last paragraph in 4.3 
has

> Furthermore the CoAP based solution requires changes in the CoAP
> layer and requires different handling for group messages compared to
> unicast communication.
> The Shim layer solution is transparent for the CoAP layer and can
> also be reused for other multicast protocols over UDP. The Shim
> layer solution, if needed, can also be adapted to DTLS record layer
> with some additional changes to the DTLS record format.

Which pretty much also says that the preferred solution is the shim 
solution.

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

If I take out section 4, and about 8 paragraphs in section 3 that 
specifically mention PK, then this document reduces down to pretty much 
mapping symmetric key multicast to DTLS.  The amount of editing to turn 
this into a pure symmetric key document is minimal.

My problem with this specific approach to writing the document is that 
you've got a solution, and you're trying to make it fit some problem.  
The DOS scenario you're writing really doesn't exist and spending time 
and effort on trying to craft a symmetric key solution for it seems 
somewhat strange.

> *//*
>
>
> 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. /*
>
>
Not that exactly.  I think I saw something pretty similar to this in 
another standards context.  Maybe not IETF, but the document format and 
content was very very similar.  I can't remember when/what at this point.

> 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./*
>
>
As I noted in my other email, if your intention   is to publish 
draft-keoh-dice-multicast-security as an Informational non-WG RFC 
describing what your company does with SK, I have no issues with that.  
I will note that the expected status for the current version of the 
draft is still Standards Track and I do have an issue with that with the 
document in its current form.

If we're specifying symmetric key DTLS multicast for constrained 
environments, then that's supposed to be a PROFILE of symmetric key DTLS 
multicast which means that SK DTLS multicast actually has to work in the 
general case, and not just lightbulbs.   Alternately, SK DTLS multicast 
for DICE has to be constrained so it *can't* be used for the general 
case - but I have no idea how you'd do that.

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

IP layer multicast doesn't have a barrier to entry.  Forwarding entities 
for the multicast group (e.g. routers, APs etc) don't have to be 
subscribers and will happily forward multicast traffic to/from anyone.  
So there's the basically problem of IP multicast traffic showing up at a 
node and not verifying at the ?? transport layer ?? application layer ?? 
depends??   If the acceptance criteria is group symmetric key, then any 
group member can DOS any other group member (or the group), and any 
attacker who breaks into even a single node can do the same.  The more 
geographic (or topologic) area covered by the multicast group, the 
easier the hack is and the harder the protections are.

I keep getting whipshawed by the arguments in this case - first its "no 
this will only be used in a secure building on a private network" and 
then its "no, this can be used in wide area multicast".  I don't think 
either of these are reliable design criteria and I wouldn't consider 
either to be enforceable in the build out of an IOT mesh.  That suggests 
that we have to design for the worst case of the wild wild internet and 
not the peaceful backwater of someone's home.

Mike