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

Alissa Cooper <alissa@cooperw.in> Wed, 31 August 2016 14:07 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 7FB9D12DBE1; Wed, 31 Aug 2016 07:07:54 -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=Ejb1x8Jc; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=IgM4FVYd
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 rA2VD8m2wBGV; Wed, 31 Aug 2016 07:07:48 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B772E12DC70; Wed, 31 Aug 2016 06:53:18 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D132020349; Wed, 31 Aug 2016 09:53:17 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 31 Aug 2016 09:53:17 -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=V6HnEOkUxIoqbHiqySL/T8MUkv4=; b=Ejb1x8 Jcke0uxGrO5YgvswsgFJr+c3oZNX0wdJawlbFQbe8k80rBDA9uyMPCa0bDxRxD0J 3GFDFgXCDYvEu8he7ueGUOJqqueWaTrtFayiRCvKzujBHnG55eKAA/bD6f9yixsr asM7GeKnGRK6v8t4lDwhbAuXBqvg29Fj+mqI8=
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=V6HnEOkUxIoqbHi qySL/T8MUkv4=; b=IgM4FVYdxf2P/loZzOLrPKjC1wmaeA2g0/vUE1h0TBFlDRv nhGfyeT0ATTg0n+N928L0iMXWPi2UfuG1dLpt/jb6WznMtKOdRQqSZ0dksGoGXIU Vbk4kkLVbIkntp0X9kDCz00P11hClj+uPiY8XELQdDyocrOAt1L2q7QFZDEU=
X-Sasl-enc: yguwGFVPCDcPXeqNhfI6msU6DAw9skk5R8S56wGYHOy+ 1472651597
Received: from sjc-alcoop-8819.cisco.com (unknown [128.107.241.183]) by mail.messagingengine.com (Postfix) with ESMTPA id 99A57F29D2; Wed, 31 Aug 2016 09:53:16 -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: <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in>
Date: Wed, 31 Aug 2016 09:53:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <730688AE-3DDE-4677-B4C9-A4173756175A@cooperw.in>
References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mIVxBuOKPBoLsMt0rxre0KZ4cvk>
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, 31 Aug 2016 14:07:54 -0000

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 °
>