[secdir] Early SecDir Review of draft-ietf-p2psip-share-08

Russ Housley <housley@vigilsec.com> Fri, 01 April 2016 14:49 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762DC12D633; Fri, 1 Apr 2016 07:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.851
X-Spam-Level:
X-Spam-Status: No, score=-100.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC7MG7mWUr1E; Fri, 1 Apr 2016 07:49:51 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id F36B112D197; Fri, 1 Apr 2016 07:49:50 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6478BF2403D; Fri, 1 Apr 2016 10:49:50 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ZRxom3iaqzrc; Fri, 1 Apr 2016 10:35:36 -0400 (EDT)
Received: from dhcp-88a7.meeting.ietf.org (dhcp-88a7.meeting.ietf.org [31.133.136.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C3E21F2403B; Fri, 1 Apr 2016 10:49:48 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 31 Mar 2016 19:21:55 -0400
Message-Id: <077CD27B-ED2C-43B9-844F-D8ADA21B279E@vigilsec.com>
To: draft-ietf-p2psip-share.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ABb8goz2EvwHFQfFh2XcqLjc2hM>
Cc: Alissa Cooper <alissa@cooperw.in>, IETF SecDir <secdir@ietf.org>
Subject: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 01 Apr 2016 14:49:52 -0000

I reviewed this document for the Security Directorate after a request
by the ART AD for an early review.

Version reviewed: draft-ietf-p2psip-share-08


Summary: Not Ready (from a Security Directorate perspective)


Major Concerns:

In Section 3.1, there is an algorithm for assigning index values, and
the text says that the high-order 24 bits of the Node-ID serve as a
pseudo-random identifier.  Since these 24 bits are obtained from the
certificate that will be used to sign the stored data, the I think that
the same bits will be used over and over.  If I got this correct, then
they are not pseudo-random.

In addition, Section 3.1 points to RFC 3550, Section 8.1 for a
discussion of the probability of a collision.  The consequences of a
collision seem to be different in the two documents.  The consequences
of a collision in the index should be clearly described in this
document.


Minor Concerns:  None


Nits:

Please pick one spelling for Resource-IDs. (This is the spelling used
in RFC 6940.)  However, this document sometimes uses "Resource Id".

Section 4.1 includes several examples for array indices.  All of
them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003,
0x123abc004, and 0x456def001.  The most straightforward solution is
to drop one of the zero digits.

To improve readability, I think the first sentence of Section 5.1
should read: "In certain use cases, such as conferencing, it is
desirable..."

Section 5.1 says:

   When defining the pattern, care must be taken to avoid conflicts
   arising from two user names of witch one is a substring of the other.

I think this paragraph would be improved with an acceptable example and
a problematic example.

In Section 5.3: s/AOR/Address of Record (AOR)/

In Section 6.2: s/This allows to invalidate entire subtrees/
                 /This allows the invalidation of entire subtrees/

In Section 8, please provide a reference for RELOAD.