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

Alissa Cooper <alissa@cooperw.in> Thu, 22 September 2016 00:41 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 56FC412BA52; Wed, 21 Sep 2016 17:41:19 -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=cIszTHv7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=oot2tw4H
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 fKNoP3_ksTah; Wed, 21 Sep 2016 17:41:17 -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 213F012BB9C; Wed, 21 Sep 2016 17:41:17 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7759F205B4; Wed, 21 Sep 2016 20:41:16 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 21 Sep 2016 20:41:16 -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=PS7ElPejRibDzAzcfQNVyOKuT2s=; b=cIszTH v7DSBS4hyGeS5zty/ijCrOfkSoeQ49R6vlMAZBx3s6anhUqNsqkMkMfOsKcbquzd K17cQ+0Rs5c6u3iisKXhEi04gACyTqsZ+qhbBJy9yVMtnx2sH/PLXbA9qSxPg8pI Fj5oFxysiz/KRCK+2E36HECXORMo7sTyKsO0M=
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=PS7ElPejRibDzAz cfQNVyOKuT2s=; b=oot2tw4HiY9GmFr2hod79hC7ZEVPnyaMXmPumjQztRniwnp DWrypdeL8JU5oXqUTZWwJ4ij3Mpo0edQ7OfxnhEzGX22DAvNCjO3Qshj/jEA/3w+ 0wU4MgTM/3FO5lvMghRQJjyA8kdPHFObpbG2fyU7BK5GwNkCxImdCMcbeqC4=
X-Sasl-enc: +kEx+0Q6oWfsJlPFzoyi9Dk3WOtx9JlUOv4SXax4jW+j 1474504875
Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D45FF2985; Wed, 21 Sep 2016 20:41:15 -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: <730688AE-3DDE-4677-B4C9-A4173756175A@cooperw.in>
Date: Wed, 21 Sep 2016 20:41:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3498DE2-67A1-4BF4-B006-1EC1D21FD256@cooperw.in>
References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in> <730688AE-3DDE-4677-B4C9-A4173756175A@cooperw.in>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/kSqCF_3FEtbOCGYT5pyig38VuXE>
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: Thu, 22 Sep 2016 00:41:19 -0000

Hi Russ,

Do you plan to respond to Thomas’ question? If we don’t hear back from you by Sept 28, I’ll ask him to go ahead with whichever solution he thinks is best and we’ll continue progressing the document.

Thanks,
Alissa

> On Aug 31, 2016, at 9:53 AM, Alissa Cooper <alissa@cooperw.in> wrote:
> 
> Hi Russ,
> 
> Any update on this?
> 
> Thanks,
> Alissa
> 
>> On Aug 24, 2016, at 10:03 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>> 
>> 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 °
>> 
>