Subject: [secdir] draft-ietf-manet-packetbb-sec-08 SecDir review

From: Donald Eastlake <[email-masked]>
Date: Wed, 29 Feb 2012 10:53:45 -0500

My apologies for getting this review in late.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Overall, I do not have security concerns with this document. See
comments below.

This document describes "signature" and "time" building blocks for
constructing messages/packets as described in RFC 5444. There is
actually noticeable overlap with Section 7.1 of RFC 5444, enough that
I am inclined to say that this draft should indicate the it Updates
5444.

The Security Considerations Section says "...  has the same security
considerations as [RFC5444]." In turn, RFC 5444 says "This
specification does not describe a protocol; it describes a packet
format.  As such, it does not specify any security considerations;
these are matters for a protocol using this specification." :-) But,
in fact, the Security Considerations Section of 5444 continues with
design suggestions for authentication/integrity and confidentiality.
Arguably, this draft provides a more detailed syntax with some
processing rules for authentication/integrity with signatures
extending 5444. But it still defers much to any specific MANET
protocol making use of RFC 5444, this draft, and probably additional
"building block" drafts or RFCs.

It appears that the MANET WG is approaching all this through a series of
overlapping documents each of which is of limited content but provides
more details. For example, this draft sets up hash function and
cryptographic function IANA registries but provides only the identity
function as initial content for these registries. Presumably additional
documents will request allocations from these registries for other
functions. There is nothing inherently wrong with this approach and
trying to produce large monolithic documents can have problems. But a
swarm of smaller inter-related and partly overlapping documents can be
confusing.

Section 8.1 and 9.1: These sections provide that when adding a packet
or message signature TLV, respectively, any pre-existing packet or
messages signature "MUST" be removed, etc., before signature calculation but
only "SHOULD" be restored afterwards. I would have guessed that
"SHOULD" would be a "MUST". In any case, it might be good to say when
you don't need to restore a signature TLV, which I would assume would
be if that signature TLV is not needed by the recipient.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]