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:
> [SK] I am afraid you have the wrong conclusions from the London meeting.
> The DICE WG reporthttp://www.ietf.org/mail-archive/web/dtls-iot/current/msg00200.html
> " In the meeting there was good agreement that draft-keoh-dice-multicast-security-05 is a reasonable
> solution for what we were chartered to do, and we should not try to add source authentication to the
> DTLS record layer. It was agreed to encourage a straw-man draft to be written exploring if an alternative
> approach would make sense doing this in CoAP including source authentication. This is not in our charter,
> but the draft is meant to help us determine how to proceed."


I'm going to hit this one separately and first.    In a private message 
to Zach I disagreed that there was "good agreement" and disagreed there 
was consensus that the draft was a "reasonable solution".  Neither of 
the comments in the meeting report appeared to me to be supported by the 
discussion at the meeting.

The actual working group minutes with the transcript are

>     
>            3) Multicast draft [Sandeep Kumar]
>            draft-keoh-dice-multicast-security-05  <http://tools.ietf.org/html?draft=draft-keoh-dice-multicast-security-05>
>            
>            - Sandeep - Goes over motivating use cases and requirements
>            - Sandeep - Goes over proposed solution (use DTLS rcord layer to protect
>            CoAP group comm messages; out of band setup of Group Security Association)
>            - Sandeep - DTLS record layer adaptation, and DTLS recrd layer processing
>            remains nearly unchanged
>            - Stephen Farrell - Just skip to open questions as we already discussed
>            this previously
>            
>            - Zach - We are chartered for this approach as described by Sandeep.
>            Now we have suggestions by Mike and others to go beyond this solution
>            which is a good discussion.  Like requiring source authentication.
>            As a WG do we need to support this?
>            - Eker - You should abandon DTLS record layer to support multicast [if
>            you want to support source authentication].  Source authentication is
>            really required for many IoT use cases.
>            - Zach - Should we try to extend CoAP to do this (instead of DTLS
>            record layer)?
>            - Carsten - Want to avoid complicated re-design.  Don't know what
>            component we could use for source authentication?
>            - MikeStJohn - Public key integrity can be done in several ways
>            - Eker - There may be problems with this depending on what layers you
>            are doing this
>            
>            - Zach - We have a solution that fits the charter but may need to support
>            source authenticaton.  We need to have complementary drafts looking at
>            alternate solutions
>            - Stepehen Farrell - Sounds like a potentially huge increase in scope
>            - Zach - Yes, we need if weto decide  really want to expand the scope
>            - Stephen Farrell - So we should hold this draft until the complementary
>            drafts are written
>            - Zach - Yes

1) You can't do integrity protection without source authentication.
2) You can't do source authentication with symmetric key systems 
(without the caveats I've listed multiple multiple times)
3) You can't use secure multicast for control systems without some form 
of integrity protection and source authentication and that was the only 
use case that has been proposed so far.

The fact that DTLS multicast security is part of the charter does not 
mean that the group is going to actually be able to produce something 
that works.  There are reasons why multicast security even at other 
layers is not widespread.

> This straw-man draft is meant for the*WG*  to decide if public-key based solution is the way to go forward with the associated
> changes required at CoAP layer, handling group/unicast communication differently and with the added
> computational load of public key signature per message. It may be a good solution on paper but I myself doubt
> its practicality.

In most ways, this should actually be a CoAP WG issue and not a DTLS WG 
issue.  I was surprised when the suggestion was made that the charter 
might be expanded.

>
> Additionally draft-keoh-dice-multicast-security can be moved to Informational since we all agree that it does
> solve a practical problem in the Lighting domain.

My definition of "solve" is probably a bit more rigorous than yours in 
this case.  My analysis is that multicast security (as you're defining 
it) for your lighting domain problem provides little or no protection to 
active attacks.  If a hacker wants to control your lights, he will grab 
one of them, extract the keys and start blinking SOS (or perhaps 
something more rude).  This will take about 5 minutes.

That said, if you're going to remove this from the WG and submit it as 
an informational RFC describing how your company does lighting multicast 
security, I have no further objections (and that's what I thought you 
were going to do post London).

My objection to draft-keoh-dice-multicast-security is as a WG, general 
solution for DTLS multicast and the possibility that it would be 
published as a IETF standard.   The implementation constraints necessary 
for your approach to ensure even minimal protection do not map well to 
an IOT of 10's of 1000's of cheap devices.  Publishing a DTLS multicast 
security standard "for constrained devices" is supposed to be a profile 
of DTLS multicast security which implies that DTLS multicast security 
needs to work for more than just the DICE cases (or can be constrained 
in the protocol so it *only* works for the DICE cases and can't be used 
as a general DTLS multicast solution).


Mike