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

Alissa Cooper <alissa@cooperw.in> Wed, 24 August 2016 14:03 UTC

Return-Path: <alissa@cooperw.in>
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 74E5612D94A; Wed, 24 Aug 2016 07:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=r4QAEHPg; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=LVQAJL8V
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 yXqbrct95Cs2; Wed, 24 Aug 2016 07:03:40 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D6512D140; Wed, 24 Aug 2016 07:03:39 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 44BB0203F4; Wed, 24 Aug 2016 10:03:38 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 24 Aug 2016 10:03:38 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Dv3uEpCGr6spGnT4KQX1tHin8Ec=; b=r4QAEH PgoktrxetSYI3sMEN2Ot+cHTRh2D6duaNeUu/81vreYj7czwft0OeP9WE/nMBYRr ele4YDk12KQfQVRStpkkK+tzcMG9gGPZs+o+ewKuRTHqluLkS9puXZiM3vSH/2il gXvZAsa/OzgTarUcWcirvFDfxUbTTF/I7FiJE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Dv3uEpCGr6spGnT 4KQX1tHin8Ec=; b=LVQAJL8VXjMXpkg300sy075gG4HwJkkNiP1gv6oA5tUcRIL Y4Xo8YQarEV5vpXeuh/8hkpECqpwbesVisibEARlX6wN9K4CHGQ0EqoiMTLZLrzZ 91Vfofo2rDDwZ//MxwXq+tNud9t5cd0HbeCjBuKImHy/uPgOOrs8krOgIEzo=
X-Sasl-enc: uJkOtaHmVB2yg/0ZGLPvjvHj7VtcL2iOYWwoWmjqYNWc 1472047417
Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 05C4CF29D0; Wed, 24 Aug 2016 10:03:36 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de>
Date: Wed, 24 Aug 2016 10:03:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in>
References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MNXUkAAWjXKZd6OFDcloHcnuMwo>
Cc: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>, "draft-ietf-p2psip-share.all@ietf.org" <draft-ietf-p2psip-share.all@ietf.org>, 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: Wed, 24 Aug 2016 14:03:44 -0000

Russ,

Any thoughts on the question Thomas poses below?

Thanks,
Alissa

> On Aug 15, 2016, at 3:20 PM, Thomas C. Schmidt <t.schmidt@haw-hamburg.de> 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: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °