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

[Alissa Cooper <[e-mail]>]

Russ,

Any thoughts on the question Thomas poses below?

Thanks,
Alissa

> On Aug 15, 2016, at 3:20 PM, Thomas C. Schmidt <[e-mail]> wrote:
> 
> Russ,
> 
> I'm only now coming back to this long delayed issue - sorry for that.
> 
> Let me summarize the story about indexing (Section 3.1 in ShaRe):
> 
> 1. The application use case for shared resources is that of a small group of peers sharing a data structure, which can be an array. Array indexing according to Sec. 3.1 uses parts of the Node-ID (the 24 least significant bits of a SHA-1 hash) to generate isolation among peers, and at the same time generate an unambiguous, unique binding between a node and the array elements it is allowed to write.
> 
> 2. The threat of collisions is that this binding becomes ambiguous and - if not prevented - would cause an option for theft of resource/service. There is no threat of privilege escalation, here, as entries are signed.
> 
> 3. SHA-1 is collision-resistant and the probability of collisions is expected to be low [1], but the output is not perfectly random. So I agree that the ref to the RFC 3550 calculation is a bit too optimistic. However, neither me nor a crypto colleague could find a rigorous calculation of the SHA-1 collision probability ...
> 
> 4. The straight-forward counter measure against theft of resources in the case of a collision is a refusal of overwriting by the storing peer (see end of Section 6.1). This may exclude a node with colliding ID bits from participation in sharing a resource.
> 
> Now I see two choices:
> 
> (1) We leave it that way, i.e., clarify the text in Section 3.1 and point out that a node under collision could re-join the overlay with a different node-ID.
> 
> (2) We could advise a procedure to generate non-colliding ID bits by rehashing the node-ID. I.e., a node that experiences a collision could rehash its ID to obtain new ID bits and the storing peer could validate by also iterating the hashing.
> 
> (2) would complicate the whole process for considerably rare cases, why I'm in favor of (1).
> 
> What would you suggest?
> 
> Thanks,
> Thomas
> 
> [1] K. Chung, M. Mitzenmacher, and S. Vadhan: Why Simple Hash Functions Work: Exploiting the Entropy in a Data Stream, Theory of Computing , vol 9, pp. 897-945.
> 
> 
> 
> On 01.04.2016 01: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] °