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

From: Michael StJohns <[email-masked]>
Date: Tue, 04 Feb 2014 15:23:22 -0500

I've read through all of the versions of this document a number of times 
and I don't think its progressing in a useful direction as of yet.

Some of this I've said before, but bear with me.

1 - Application use cases do not translate to DTLS multicast:

Section 2.1 of the document has basically four use cases, which actually 
seem to reduce down to one or possibly two actual use cases:   A control 
function and in information retrieval function - the light control, the 
parameter update and the firmware update are all control functions 
(albeit with differing latency requirements), the commissioning function 
seems to be more of of "anyone home" or something similar to what 
happens when you ARP for a broadcast address on a subnet.

DTLS multicast appears to assume a single symmetric key per application 
without regard to the number of nodes in the multicast mesh.  But since 
the key is widely possessed, there is no useful approach to using that 
key for sender authentication as anyone who possesses that key can spoof 
being anyone else.  In the control use cases, what you actually want is 
a strong and authenticated divide between those nodes that are 
controllers and those nodes that are being controlled.  A more 
appropriate combination of protocols would be a multicast L3/L4 (udp 
over IP multicast) for package distribution, and a digital signature L5 
wrapped around the application data.

For something larger, like firmware, an even more appropriate 
combination may be a unicast L3/L4 with an L5 multicast application 
which is responsible for verifying the package and its parts before 
redistributing them to its neighbors.  (NOTE WELL - this might not be 
COAP).  Even something like large application packages like firmware can 
be managed by sending out a signed table of hashes where each hash 
covers a portion of the firmware and where the hash can be used to 
verify received firmware segments before re-broadcasting them.

Section 2.2.h hints at using public key as part of DTLS - but then 
suggests it's too expensive an approach.  I think we need to get past 
this constant "I'm too small for public keys" argument and just say that 
public key technology is going to be needed even in the smallest 
devices.  I'm sure that costs will come down sharply and quickly.

I'm finding it hard to see how the use cases in the document argue at 
all for a DTLS multicast.

2 - "Two can keep a secret if one is dead" - Or "As the number of 
entities that know a secret increase, the probability of that secret 
being secret approaches zero".  The systems that have successfully used 
secured multicast in the past have either been closed systems within a 
broader security perimeter (e.g. US DOD's Simnet testbed) or small 
collections of nodes with identical security domains with reasonable 
physical security (e.g. networked bridge sensors, earthquake sensors).

Section 2.2 suggests that DTLS multicast needs to scale up to 255 
senders and up to 5000 listeners, but it's probable (approaching unity) 
that a system of that size would be trivial to compromise, especially 
with the assumption that the nodes of the multicast mesh would be made 
up of devices or implementations from widely varying providers with 
widely varying skillsets and implementation rigor.

Mitigations in the form of hardware security are possible, but that 
probably defeats the base purpose of making things work for low powered 
devices.

3 - The need for source authentication is hand waved, rather than 
analyzed.  Section 2.2.h suggests that "source authentication is not a 
critical function to be always enabled in every LLN use case".  But the 
use cases from 2.1, with the sole possible exception of the 
commissioning case (and it's unclear it's an exception) are "control" 
cases where it's necessary for a node to know who's telling it to do what.

Instead of just throwing this to the side, the discussion on source 
authentication needs to be brought to front and center and the 
combinations worked through and then matched to the use cases.

Of all the issues with this document, I believe this one to be fatal and 
would argue against adoption as a WG item without resolving this.

4 - The need for encryption is assumed, without any actual analysis 
being done (Section 2.2. d).  Basically, there is a cost for 
confidentiality, that should be measured against need and threat.  
Confidentiality may be needed for responses to prompts for information, 
but that suggests that the inbounds response is actually unicast DTLS 
rather than multicast DTLS.  For control multicast, it's unclear why 
it's important to encrypt "turn off the lights".  Again, commissioning 
may be an exception, but please see item 2 above - is it really a secret 
when shared with 1000s of devices?

5 - There are mis-statements of the protections provided:

Section 4.4, third para:"this guarantees that no one has spoofed the 
SenderID, as it protected by the MAC".  Any node that has the sending 
key can trivially forge this message and set the SenderID to any value 
desired.

There is a trivial attack related to this which is for an attacker to 
send out a valid message but with a max sequence number (and for all 
known senderIDs).  That would prevent further use of that particular key 
and sender.  Windowing may help, but all it does is slow down the attack.

____________________________________________
A general security principle is that symmetric keys should be only 
shared between at most two entities, and that private asymmetric keys 
should be only known to one entity.  Those are guidelines, not hard 
rules, but there has to be substantial benefit for violating them, and a 
reasonable expectation that at least *some* residual security is possible.

This document doesn't describe sufficient benefits to warrant violating 
them, and the mechanisms described lack sufficient residual security 
assuming your scaling numbers.

I'm not looking for perfect security, but I would really prefer 
something that won't be broken before it's deployed.

Mike

On 1/17/2014 10:54 AM, Kumar, Sandeep wrote:
> Dear Dice members
>
> A new version of the "DTLS-based Multicast Security" draft has been uploaded. The new version takes into consideration the constructive comments received during the DICE meeting in Vancouver, comments on the list and privately.
>
> Comments on the new version are welcome.
>
> Kind regards
> Sandeep
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 17, 2014 4:50 PM
> To: Kumar, Sandeep; Garcia Morchon, Oscar; Kumar, Sandeep; Sye Loong Keoh; Dijk, Esko; Garcia Morchon, Oscar; Dijk, Esko; Sye Loong Keoh
> Subject: New Version Notification for draft-keoh-dice-multicast-security-03.txt
>
>
> A new version of I-D, draft-keoh-dice-multicast-security-03.txt
> has been successfully submitted by Sandeep S. Kumar and posted to the IETF repository.
>
> Name:           draft-keoh-dice-multicast-security
> Revision:       03
> Title:          DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs)
> Document date:  2014-01-17
> Group:          Individual Submission
> Pages:          19
> URL:            http://www.ietf.org/internet-drafts/draft-keoh-dice-multicast-security-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/
> Htmlized:       http://tools.ietf.org/html/draft-keoh-dice-multicast-security-03
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-keoh-dice-multicast-security-03
>
> Abstract:
>     The CoAP and 6LoWPAN standards are fast emerging as the de-facto
>     protocols in the area of resource-constrained devices.  Such IP-based
>     systems are foreseen to be used for building and lighting control
>     systems where wireless devices interconnect with each other, forming
>     low-power and lossy networks (LLNs).  Both multicast and its security
>     are key needs in these networks.  This draft presents a method for
>     securing IPv6 multicast communication in LLNs based on the DTLS which
>     is already present for unicast in these CoAP devices.  This draft
>     deals with the adaptation of the DTLS record layer to protect
>     multicast group communication, assuming that all group members
>     already have the group security association parameters in their
>     possession.  The adapted DTLS record layer provides message
>     confidentiality, integrity and replay protection to group messages
>     using the group keying material before sending the message via IPv6
>     multicast to the group.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> ________________________________
> 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.
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot