Subject: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00]

From: John Foley <[email-masked]>
Date: Thu, 17 Oct 2013 14:32:58 -0400

Hello colleagues,

I've reviewed your draft for DTLS-based multicast security for low-power
and LLNs.  Please give consideration to my comments for your draft. 

Section 1.1:  It's been a while since I've done multicast work.  This is
a nit, but isn't the traditional term used for a device receiving
multicast packets called a "Receiver"?  Using the term "Listener" may
confuse traditional IP multicast experts.

Section 4.1.1:  How can we trust this ChangeCipherSpec message?  Since
all the detail of the DTLS handshake, security association setup, group
setup, etc. are omitted from this draft, how do we know this
ChangeCipherSpec is valid?  This appears to be an easy opportunity for a
denial of service attack.  Comparing to TLS, TLS handshake messages are
hashed and validated (RFC 5246 section 7.4.9).  Additionally, some
handshake messages are digitally signed (RFC 5246 section 7.4.3).  It
seems we need much more detail in this draft regarding re-synchronizing
the epoch and seq# using the ChangeCipherSpec message.  Or, consider
using the approach defined in [draft-mcgrew-aero-00], which
eliminates the need to synchronize the seq#.

Section 4.1.2:  What's wrong with using the IP address as the sender
ID?  If the IP address is included in the MAC, this provides the
equivalent level of security as using the Sender ID.  The added benefit
would be no need to reduce the size of the sequence number. 
Additionally, protocols such as IGMP and PIM will use the source IP
address to route many-to-many multicast packets.  Using the IP address
as the sender ID in this draft may allow for better cohesion with the
network management entities and provide for more intelligence in
security products such as firewalls and intrusion prevention.

Section 4.2.1:  How does a listener join an existing multicast feed
while not failing the anti-replay check?  This new listener will not
know which sequence numbers are valid unless there's some form of
synchronization logic, which doesn't appear to be defined in the draft. 
You may want to look at incorporating [draft-mcgrew-aero-00].  This
allows for anti-replay protection while not needing to maintain state on
the receiver side.  AERO solves the problem of synchronizing the
sequence number for late multicast joiners.  This reduces the code
footprint and complexity, which may be very beneficial for constrained
devices.

General comment:  You may consider adding a section regarding IGMP and
PIM.  Should the reader assume there are no ramifications to IGMP/PIM? 
Any entity could join the multicast group and receive packets, albeit
they will not be able to decrypt them.  Or, is this protocol intended to
only be used on local subnets?  My point is maybe you should provide
some context with respect to how multicast networks are typically deployed.

Best regards,
John Foley