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

[Alissa Cooper <[e-mail]>]

Hi Russ,

Any update on this?

Thanks,
Alissa

> On Aug 24, 2016, at 10:03 AM, Alissa Cooper <[e-mail]> wrote:
> 
> 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] °
>