Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-packetbb-sec-09

[Ballot comment]
I really think you're doing the wrong thing with two
registries (see below). However, it could work so
I'll leave it at that if I've not managed to
convince you to change it.

I also think the change to key identifiers ought
be brought to the WG list for checking. I'm going to
assume that the authors, WG chairs and AD will ensure
that we're doing the right thing here and not breaking
anyone's code on them without saying first on the WG
mailing list.

There are a few occurrences of "signed" that might
be better worded after the Signature->ICV terminology
change.

[Ballot comment]
minor nit - TLVs is plural of "Type-Length-Value" not "Type-Length-Value structure" and expansion is NOT REQUIRED

It's a bit confusing putting a mini-IANA section in the Intro.

Section 13 after "This specification requests" a number of the terms defined are not used in the document.

[Ballot discuss]
Section 10.2 says "If both a TIMESTAMP TLV and a SIGNATURE TLV are associated with an address, the TIMESTAMP TLV  SHOULD be considered when calculating the value of the signature".

"be considered" is vague - can it be made more precise? Is this trying to say the signature should cover the timestamp?
If so, how is this interoperable as a SHOULD instead of a MUST?

[Ballot discuss]
I have a number of discuss points here. Maybe some of this is just
that I don't have the right context but I find it hard to see how
this is really baked as-is. I guess I'm wondering if it would perhaps
be better to wait until someone actually does an implementation? (The
write-up says there are none known.)

#1 I don't understand why this does not define any actual algorithms.
Is there another document going to do that? If not, then what's the
point of this being on the standards track with no algorithms and no
automated key management? I don't see any MANET WG documents that
will obviously provide those nor any relevant milestones. (Mind you,
all the milestones are dated 2007;-)

#2 Does this allow or preclude MACs such as HMAC-SHA1?  If the former
then you need to change terminology as those are not signatures. (I'd
suggest integrity check value instead.) If the latter, then why do
you want to prevent that? While I don't care too much about the
specific terminology, (others do though), you definitely need to be
clear if you really mean only digital signatures or not.

#3 I don't understand why an 8-bit key index is sufficient for a
large network. (And key index is not really a good term, I think key
identifier would be much better.) With key rollovers and some form of
key derivation for different directions (to prevent reflection
attacks) and maybe two different key usages for different kinds of
message or something like that, that would mean only
supporting 32 unique keys values for a given purpose in the
entire network which just seems too small. I'd suggest changing
that to a key identifier length-value field or at least providing some
way to identify key number 257 and beyond.

#4 Are "badly formed" and "insecure" assumed to be the same?  (Section
4 implies they are.) If so, that would seem to preclude any MANET
routing scheme where a node might forward cryptographic fields but
not act upon a routing message that it understands but cannot verify.
Was that considered by the WG and was it rejected?  Rejecting that
seems to imply that all nodes need to be kept up to date with all
keying material all the time which seems brittle and would also seem
to make it very hard to introduce a new algorithm except as a flag-day
or by having all nodes add fields for all algorithms.  (Which in turn
implies MANETs will remain tiny so that this will be practical or
that large MANETs won't be able to use security.)

#5 I don't understand why you don't define at least one timestamp
precisely.  Why would you want 250 varieties of timestamp anyway?

#6 Having separate hash and cryptographic function registries might
not be the best plan since not all combinations will make sense.  Is
that really a good idea? Why not make use of some other registries
that already exist? (That is, is there a particular reason why you
need new registries or have you looked but not found one that'd
work?)

[Ballot discuss]
I have a number of discuss points here. Maybe some of this is just
that I don't have the right context but I find it hard to see how
this is really baked as-is. I guess I'm wondering if it would perhaps
be better to wait until someone actually does an implementation? (The
write-up says there are none known.)

#1 I don't understand why this does not define any actual algorithms.
Is there another document going to do that? If not, then what's the
point of this being on the standards track with no algorithms and no
automated key management? I don't see any MANET WG documents that
will obviously provide those nor any relevant milestones. (Mind you,
all the milestones are dated 2007;-)

#2 Does this allow or preclude MACs such as HMAC-SHA1?  If the former
then you need to change terminology as those are not signatures. (I'd
suggest integrity check value instead.) If the latter, then why do
you want to prevent that? While I don't care too much about the
specific terminology, (others do though), you definitely need to be
clear if you really mean only digital signatures or not.

#3 I don't understand why an 8-bit key index is sufficient for a
large network. (And key index is not really a good term, I think key
identifier would be much better.) With key rollovers and some form of
key derivation for different directions (to prevent reflection
attacks) and maybe two different key usages for different kinds of
message or something like that, that would mean only
supporting 32 unique keys values for a given purpose in the
entire network which just seems too small. I'd suggest changing
that to a key identifier length-value field or at least providing some
way to identify key number 257 and beyond.

#4 Are "badly formed" and "insecure" assumed to be the same?  (Section
4 implies they are.) If so, that would seem to preclude any MANET routing
scheme where a node might forward cryptographic fields but not act upon
a routing message that it understands but cannot verify. Was that considered
by the WG and was it rejected?  Rejecting that seems to imply that all nodes
need to be kept up to date with all keying material all the time which
seems brittle and would also seem to make it very hard to introduce a
new algorithm except as a flag-day or by having all nodes add fields
for all algorithms.  (Which in turn implies MANETs will remain tiny
so that this will be practical.)

#5 I don't understand why you don't define at least one timestamp
precisely.  Why would you want 250 varieties of timestamp anyway?

#6 Having separate hash and cryptographic function registries might
not be the best plan since not all combinations will make sense.  Is
that really a good idea? Why not make use of some other registries
that already exist? (That is, is there a particular reason why you
need new registries or have you looked but not found one that'd
work?)

[Ballot comment]
- Title seems misleading reading the abstract. Suggest adding mention
of timestamps in title and fixing signature term as per discuss point 1.

- Using the term "unsigned timestamp" in 13.2 seems like a bad choice
given that a you're using signature all over the place.  I'd suggest
qualifying that.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (MANET Cryptographical Signature TLV Definition) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'MANET Cryptographical Signature TLV Definition'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document describes general and flexible TLVs (type-length-value
  structure) for representing cryptographic signatures as well as
  timestamps, using the generalized MANET packet/message format defined
  in RFC 5444.  It defines two Packet TLVs, two Message TLVs, and two
  Address Block TLVs, for affixing cryptographic signatures and
  timestamps to a packet, message and address, respectively.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-packetbb-sec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-packetbb-sec/

No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD review...

Thanks for this draft. I have performed my AD review as usual and I
don't have any major issues.

Before we start, one minor question to help me set my expectations...

Did you have any expert security input on this work? I only ask in
order to try to work out what level of review we are likely to get
later in the process.

Otherwise I have a few nits and minor requests to polish the document.
I hope they are straight forward and you can quickly spin a new
revision of the document which I can advance to IETF last call.

Thanks,
Adrian

---

The text file I downloaded has a couple of interesting characters at the
top.



---

Could you s/[RFC5444]/defined in RFC 5444/               

(A piece of pettiness, but citations cannot be made from the stand-alone
Abstract)

---

Section 10.1 does not include the caveat about other signatures that may
already be present as found in 8.1 and 9.1. Is this intentional?

---

Section 11

Don't "propose" anything! This is an I-D you plan to have converted into
an RFC. You can "define" things if you feel the need for a word.

---

Section 12.1.1

  The rationale for separating the hash function and the cryptographic
  function into two octets instead of having all combinations in a
  single octet - possibly as TLV type extension - is twofold: First, if
  further hash functions or cryptographic functions are added in the
  future, the number space might not remain continuous.  More
  importantly, the number space of possible combinations would be
  rapidly exhausted.  As new or improved cryptographic mechanism are
  continuously being developed and introduced, this format should be
  able to accommodate such for the foreseeable future.

I accept the reasoning for the contiguity. I don't accept the reasoning
for number space exhaustion. Surely, you have the same number of bits
(16) and the same amount of information (#hashfuncs * #cryptofuncs).

Actually, in your method exhaustion is slightly more likely because you
only have 8 bits for each category and so one of them could become
exhausted independent of the other.

I suggest removing the second motivation.

Clarity of separation of function identifiers would serve as a second
reason if you must have one.

---

12.1.1

  The rationale for not including a field that lists parameters of the
  cryptographic signature in the TLV is, that before being able to
  validate a cryptographic signature, routers have to exchange or

s/TLV is, that/TLV is that,/

---

Section 13

Please remove the RFC2119 language from this part of the IANA
considerations section. It is typical to request IANA to perform actions.

---

Sections 13. through 13.6

The experimental ranges here are way too large unless you can give me a
really good reason.

Understandable as MANET moves from experimental to standards track, but
once you are standards track it is normal to restrict the experimental
ranges to a very small (e.g. one) range of numbers. Have a look at
RFC 3692. Consider whether it would be enough to have just one or two
code points reserved for experimentation.

  (1.a) The document shepherd for this document is Stan Ratliff
        (sratliff@cisco.com). The shepherd has personally reviewed
        the document, and believes it is ready for forwarding to
        the IESG for publication.
  (1.b) The document has had adequate review from the working group,
        and from key non-working group members. The shepherd does not
        have any concerns about the depth or breadth of the reviews
  (1.c) The document shepherd does not have any concerns that the
        document needs more review.
  (1.d) There are no concerns that the responsible Area Directors or
        the IESG should be aware of. There were no IPR disclosures
        necessary.
  (1.e) Working group consensus behind the document is solid. There
        is strong consensus behind the core of very active members in
        the working group.
  (1.f) No appeals have been threatened; no extreme discontent has been
        indicated by anyone in the working group.
  (1.g) The document shepherd has personally verified the document satisfies
        all ID nits. The document has met all formal review criteria.
  (1.h) The document has split its references into normative and informative.
        There are no normative references to documents not ready for
        advancement. 
  (1.i) The shepherd has verified that the IANA consideration section
        exists and is consistent with the body of the document. The
        reservations requested in the appropriate IANA registries.
        The IANA registries are clearly identified. The document does
        request two new IANA registries, and defines the proposed initial
        contents. It does not specifically suggest names for the new
        registries, however, the functionality is clear enough that names
        can easily be derived. The document does not outline a procedure
        for updating the registries. The document describes guidelines for
        expert review; as of this writing, the shepherd has not conferred
        with the responsible Area Director about said review.
  (1.j) The document shepherd has verified that the document has no
        sections that are written in a formal language (e.g. XML), so no
        automated checker (other than the ID nits) has been run.
  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        The document defines the mechanism for including a cryptographic
        signature for the key items in an RFC 5444 formatted packet. The
        document also specifies how mutable fields in the packet should
        be handled, such that the resulting signature can be correctly
        verified by a recipient. 
    Working Group Summary
        The document has been reviewed by the working group quite carefully.
        The document reflects the consensus of the working group.
    Document Quality
        The document has received careful review. The shepherd does not
        know of any existing implementations at this time.