Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07

"Thomas C. Schmidt" <t.schmidt@haw-hamburg.de> Mon, 08 February 2016 22:37 UTC

Return-Path: <t.schmidt@haw-hamburg.de>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9491B344F for <p2psip@ietfa.amsl.com>; Mon, 8 Feb 2016 14:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 wvvs6M19PvEt for <p2psip@ietfa.amsl.com>; Mon, 8 Feb 2016 14:37:03 -0800 (PST)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C39C1B3449 for <p2psip@ietf.org>; Mon, 8 Feb 2016 14:37:03 -0800 (PST)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from <t.schmidt@haw-hamburg.de>) id <1aSuQW-001w9o-IG>; Mon, 08 Feb 2016 23:37:00 +0100
Received: from x55b23e3d.dyn.telefonica.de ([85.178.62.61] helo=[192.168.178.90]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from <t.schmidt@haw-hamburg.de>) id <1aSuQW-0030NS-49>; Mon, 08 Feb 2016 23:37:00 +0100
To: Alissa Cooper <alissa@cooperw.in>
References: <e41784d379854608bb9a6e027848cee3@HUB01.mailcluster.haw-hamburg.de> <5698B2AA.7060008@haw-hamburg.de> <4fd3df9ac9bc49f6a2ac571a3e6b2dcd@HUB02.mailcluster.haw-hamburg.de>
From: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Message-ID: <56B91887.8010908@haw-hamburg.de>
Date: Mon, 8 Feb 2016 23:36:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <4fd3df9ac9bc49f6a2ac571a3e6b2dcd@HUB02.mailcluster.haw-hamburg.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: 85.178.62.61
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/alf2Pb4oviG85fzXZ7vfOl1EAck>
Cc: P2PSIP WG <p2psip@ietf.org>
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 22:37:06 -0000

Hi Alissa,

I'll be back with ShaRe in a few days.

Best,
  Thomas

On 08.02.2016 23:33, Alissa Cooper wrote:
> Hi Thomas,
>
> What is the status of this?
>
> Thanks,
> Alissa
>
>> On Jan 15, 2016, at 12:49 AM, Thomas C. Schmidt <t.schmidt@haw-hamburg.de> wrote:
>>
>> Dear Alissa,
>>
>> many thanks for your detailed feedback. We'll address the comments shortly and be back.
>>
>> Best,
>> Thomas
>>
>> On 15.01.2016 00:03, Alissa Cooper wrote:
>>> I have reviewed this document in preparation for IETF last call. I have
>>> a number of comments and questions that need to be resolved before last
>>> call can be initiated. I’ve also included some nits below that should be
>>> resolved together with last call comments.
>>>
>>> Given the nature of this document, I’d like for the shepherd to request
>>> an early SECDIR review after the comments below have been resolved so
>>> that the authors and WG can receive security feedback before the
>>> document progresses to IESG evaluation.
>>>
>>>
>>> == Substantive comments and questions ==
>>>
>>> = Section 3.1 =
>>>
>>> I think this section requires clarification.
>>>
>>> How is the index value supposed to be initialized? Is it supposed to be
>>> chosen at random or set to 0 (or 1, as in the figure)?
>>>
>>> I don’t understand how this mechanism relates to how SSRCs are chosen.
>>> In fact RFC 3550 doesn’t specify a particular algorithm to use, but
>>> merely provides one example. Furthermore, I don’t see how the collision
>>> probably for the array index value, which selects the least significant
>>> three bytes from a cryptographically random Node-Id that must be 16
>>> bytes or longer, would be the same as for a randomly chosen 32-bit
>>> integer. Could you explain?
>>>
>>> = Section 5 =
>>>
>>> Are variable resource names expected to be UTF-8 strings? I think
>>> somewhere in this section the internationalization expectations for
>>> these strings need to be specified.
>>>
>>> = Section 5.3 =
>>>
>>> (1)
>>> I think this section needs to specify normative requirements on the
>>> pattern construction to avoid duplicative or substring names as
>>> described in 5.1
>>>
>>> (2)
>>> "Configurations in this overlay document MUST adhere in syntax and
>>> semantic of names as defined by the context of use. For example, syntax
>>> restrictions apply when using P2PSIP[I-D.ietf-p2psip-sip], while a more
>>> general naming is feasible in plain RELOAD."
>>>
>>> I don’t understand what the normative requirement is here or why it is
>>> needed. How is “the context of use” defined? Shouldn’t it be up to the
>>> specific protocol documents to define the required syntax and semantics
>>> for specific usages (e.g., the way draft-ietf-p2psip-sip does)?
>>>
>>> (3)
>>> "In the absence of a <variable-resource-names> element for a Kind using
>>> the USER-CHAIN-ACL access policy (see Section 6.6
>>> <https://tools.ietf.org/html/draft-ietf-p2psip-share-07#section-6.6>),
>>> implementors SHOULD assume this default value."
>>>
>>> Why is this SHOULD and not MUST? Shouldn’t implementations
>>> conservatively assume that variable names are not allowed unless
>>> explicitly specified?
>>>
>>> (4)
>>> "If no pattern is defined for a Kind or the "enable" attribute is false,
>>> allowable Resource Names are restricted to the username of the signer
>>> for Shared Resource.”
>>>
>>> I think this needs to account for an error condition where the pattern
>>> does not meet the pattern construction requirements, e.g.:
>>>
>>> ""If no pattern is defined for a Kind, if the "enable" attribute is
>>> false, or if the regular expression does not meet the requirements
>>> specified in this section, the allowable Resource Names are restricted
>>> to the username of the signer for Shared Resource.”
>>>
>>> = Section 6.2 =
>>>
>>> For privacy reasons, wouldn’t it be better to overwrite every entry in a
>>> subtree when the root of the subtree gets overwritten? Otherwise the
>>> list of users who were given write access may remain long after their
>>> access has been revoked.
>>>
>>> = Section 6.3 =
>>>
>>> How strings are to be compared (e.g., as binary objects or whatever it
>>> is) needs to be normatively specified.
>>>
>>> It is confusing to use normative language only in step 5 here. I would
>>> suggest either normatively defining each action or not using SHALL here.
>>>
>>> = Section 6.6 =
>>>
>>> "Otherwise, the value MUST be written if the certificate of the signer
>>> contains a username that matches to one of the variable resource name
>>> pattern (c.f. Section 5
>>> <https://tools.ietf.org/html/draft-ietf-p2psip-share-07#section-5>)
>>> specified in the configuration document"
>>>
>>> It seems to me that matching the pattern is not sufficient — isn’t it
>>> the case that both the user and domain portions of the user name in the
>>> certificate need to match the user and domain name portions present in
>>> the resource name? In general, the document seems to be missing
>>> discussion of the implications of having the user name and the resource
>>> name diverge. I think this affects every operation that involves
>>> comparing the two (or the Resource-Id, right?).
>>>
>>> I’m also unclear about why policy for allowing access to shared
>>> resources is being strictly coupled with policy for allowing variable
>>> resource names. Might there be cases where it makes sense to authorize
>>> one but not the other?
>>>
>>> = Section 8.2 =
>>>
>>> This section misses the threat of a misbehaving peer who is delegated
>>> write access — that seems like an important case to cover.
>>>
>>> = Section 8.3 =
>>>
>>> By “publicly readable” do you mean “readable by any node in the
>>> overlay”? Admission to the overlay would still be access controlled,
>>> correct?
>>>
>>> = Section 9.2 =
>>>
>>> What is the significance of 17, other than that it is in the unassigned
>>> range?
>>>
>>>
>>> == Nits ==
>>>
>>> = Section 1 =
>>>
>>> The reference to I-D.ietf-p2psip-disco should be removed given that the
>>> document is several years old and not expected to advance as far as I know.
>>>
>>> s/from one authorized to another (previously unauthorized) user/from one
>>> authorized user to another (previously unauthorized) user/
>>>
>>> = Section 2 =
>>>
>>> s/the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts
>>> <https://tools.ietf.org/html/draft-ietf-p2psip-share-07#ref-I-D.ietf-p2psip-concepts>]/[I-D.ietf-p2psip-concepts
>>> <https://tools.ietf.org/html/draft-ietf-p2psip-share-07#ref-I-D.ietf-p2psip-concepts>]/
>>>
>>> = Section 3.1 =
>>>
>>> s/Append an 8 bit long short individual index value/Append an 8-bit
>>> individual index value/
>>>
>>> = Section 4.1 =
>>>
>>> s/an Access Control including/an Access Control List including/
>>>
>>> = Section 5.1 =
>>>
>>> Same comment about I-D.ietf-p2psip-disco
>>> <https://tools.ietf.org/html/draft-ietf-p2psip-share-07#ref-I-D.ietf-p2psip-disco> as
>>> in Section 1.
>>>
>>>
>>>
>>>
>>
>> --
>>
>> 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 °

-- 

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 °