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

["Thomas C. Schmidt" <[e-mail]>]

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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °