[secdir] secdir re-review of draft-ietf-manet-olsrv2-16

Tom Yu <tlyu@MIT.EDU> Wed, 10 October 2012 22:58 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 71F781F0C3E; Wed, 10 Oct 2012 15:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id l+3RMm3v-EyF; Wed, 10 Oct 2012 15:58:04 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU []) by ietfa.amsl.com (Postfix) with ESMTP id A12611F041F; Wed, 10 Oct 2012 15:58:04 -0700 (PDT)
X-AuditID: 1209190f-b7f636d00000095b-fd-5075fd7b67c7
Received: from mailhub-auth-3.mit.edu ( []) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.7E.02395.B7DF5705; Wed, 10 Oct 2012 18:58:04 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU []) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q9AMw3qu007194; Wed, 10 Oct 2012 18:58:03 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q9AMw0mK024025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Oct 2012 18:58:01 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu ( id q9AMvxdW014241; Wed, 10 Oct 2012 18:57:59 -0400 (EDT)
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-manet-olsrv2.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 10 Oct 2012 18:57:59 -0400
Message-ID: <ldvzk3u0waw.fsf@cathode-dark-space.mit.edu>
Lines: 45
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrVvztzTAoGEzo8Wz7j9sFjP+TGS2 +LDwIYsDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfFh2wb2gvcCFRvn2jUwnuDtYuTk kBAwkZiyr4MNwhaTuHBvPZDNxSEksI9R4ubG9ewQzgZGiT+/fzFDOFeYJDrOP2KCcLoYJdYs XcbSxcjBISLgJ9H7NxpklLCAucStBTvZQcJsAtISRxeXgYRZBFQlTv7ZyARi8wpYSLzdtZcV xOYR4JToP3mTESIuKHFy5hMWEJtZQEvixr+XTBMY+WYhSc1CklrAyLSKUTYlt0o3NzEzpzg1 Wbc4OTEvL7VI10QvN7NELzWldBMjONAk+XcwfjuodIhRgINRiYd3wfbSACHWxLLiytxDjJIc TEqivHe/A4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8CY+BMrxpiRWVqUW5cOkpDlYlMR5r6bc 9BcSSE8sSc1OTS1ILYLJynBwKEnwHvsD1ChYlJqeWpGWmVOCkGbi4AQZzgM0fDFIDW9xQWJu cWY6RP4Uo6KUOO8ekIQASCKjNA+uF5YIXjGKA70izLsWpIoHmETgul8BDWYCGiwzqQRkcEki QkqqgbFMKZJzQoQKw+nNdTvNyi9EFfdcbvhcHpQ658r6LxdqVyxXlggycs4T2vpb7uu9vlc7 HH1arFpCVlUYKqZr+WytVzIERsaOi6H6q3aHKCYZ7L2xKkg/fN+mmt6dDJ0Zi3axHHYu0PbY HF/9+lrwIaG+4AmreEX5NmiIsLRvvtE1JV90ta66EktxRqKhFnNRcSIAnt1DGN8CAAA=
Subject: [secdir] secdir re-review of draft-ietf-manet-olsrv2-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2012 22:58:05 -0000

I have re-reviewed this document, primarily by examining the changes
from the -15 version.  The authors have added references to RFC 6622,
which specifies some protocol elements that could in principle provide
any needed security properties.  These changes relegate most of my
previous concerns to RFC 6622.

Unfortunately, most of my concerns still apply to RFC 6622, which has
already been approved as Standards Track.  I am undecided as to
whether the Area Directors should treat my concerns with RFC 6622 as
reasons to block this document.  It does appear to me that a number of
security aspects of this protocol suite are deferred to possible
future work.  This may even be appropriate, depending on the risk
profile of the likely deployments.

It is not clear to me that RFC 6622 is implementable as written (are
there multiple existing implementations?), because it seems that it
leaves a number of things underspecified.  As an example, although
future specifications that register ICV (integrity check value)
algorithms might resolve these ambiguities, RFC 6622 appears to make
an underlying assumption that it is possible to decompose ICVs as:

      ICV-value = cryptographic-function(hash-function(content))

which is not in general possible.  (HMAC is but one example of how
this assumption is invalid.)  In some cases where it is possible to
make such a decomposition, such as encrypting a hash value using a
symmetric cipher, RFC 6622 does not specify necessary parameters such
as the cipher mode.  (Also, producing a message authentication code by
encrypting a hash value using a symmetric cipher can lead to

RFC 6622 leaves key management issues unresolved.

In the next to last paragraph of Section 23.2, the word "valid" should
probably be "invalid":

   Failure to
   verify an ICV included can be used as a reason to reject an incoming
   message or packet as "valid", according to Section 12.1 of [RFC6130]

should be

   Failure to
   verify an ICV included can be used as a reason to reject an incoming
   message or packet as "invalid", according to Section 12.1 of [RFC6130]