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

"Thomas C. Schmidt" <t.schmidt@haw-hamburg.de> Fri, 01 April 2016 14:53 UTC

Return-Path: <t.schmidt@haw-hamburg.de>
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 78F7E12D62E; Fri, 1 Apr 2016 07:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Zahg5McQ0MKI; Fri, 1 Apr 2016 07:53:46 -0700 (PDT)
Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8820612D588; Fri, 1 Apr 2016 07:53:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,427,1454972400"; d="scan'208";a="38554579"
Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES256-SHA; 01 Apr 2016 16:53:40 +0200
Received: from CAS02.mailcluster.haw-hamburg.de (2002:8d16:183d::8d16:183d) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 1 Apr 2016 16:53:40 +0200
Received: from [192.168.101.34] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.61) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 1 Apr 2016 16:53:40 +0200
To: Russ Housley <housley@vigilsec.com>, "draft-ietf-p2psip-share.all@ietf.org" <draft-ietf-p2psip-share.all@ietf.org>
References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de>
From: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Message-ID: <56FE8B6E.7050208@haw-hamburg.de>
Date: Fri, 01 Apr 2016 11:53:34 -0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [141.22.250.35]
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/46-tl-wW7r1N0kqLvuDZlApAYVg>
X-Mailman-Approved-At: Sat, 02 Apr 2016 08:03:41 -0700
Cc: Alissa Cooper <alissa@cooperw.in>, IETF SecDir <secdir@ietf.org>
Subject: Re: [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:53:48 -0000

Hi Russ,

thanks for the quick review. We will internally discuss and address 
within the next (IETF-) days and be back.

  Thomas

On 31.03.2016 20:21, Russ Housley wrote:
> 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.
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °