Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07
Alissa Cooper <alissa@cooperw.in> Mon, 08 February 2016 22:33 UTC
Return-Path: <alissa@cooperw.in>
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 E9B221B342A for <p2psip@ietfa.amsl.com>; Mon, 8 Feb 2016 14:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] 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 B9Bem_hnnk9t for <p2psip@ietfa.amsl.com>; Mon, 8 Feb 2016 14:33:24 -0800 (PST)
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 BCDBA1B3428 for <p2psip@ietf.org>; Mon, 8 Feb 2016 14:33:24 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 29C0B20794 for <p2psip@ietf.org>; Mon, 8 Feb 2016 17:33:24 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 08 Feb 2016 17:33:24 -0500
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=Yy6WuR5sMjwnJuU+zLS1QVAOu7s=; b=VT+H2z D+Ic+y7iThY7NihjvHZD2PixS6KMzKpB2q0E3dnMUqU+DefawW2B0V/vntKArXJP jPJdzo5z6HlTatTSy+W/Rv67lpCd+GR4VqacxqDoZ3CApB0UmmrOZeFRYbCS3MC6 vYnJl9YeETxgPnXfrElGpbdb9MIVYxKrTLPEE=
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=Yy6WuR5sMjwnJuU +zLS1QVAOu7s=; b=u9KUdP8zgfGrIZX+ur+ZwIMzjH3NnFCMlqkXMI9+ixqDQhS QanOxzzMsN4Dfs9N3Djozxna+LIpNbk5MV2oUAK3l8iZr5CEUAH+ptTDKpe4sU7t j8yOm/w6gj2MeMyKLh0Car5Puopzb+JCbFKRtfga8FFVN3QWx34yFpMF0Bn0=
X-Sasl-enc: Kti8pD0gOzIy7vP0PqaXEuafnoMqOCqQm08VgfdAWBbD 1454970803
Received: from dhcp-171-68-20-80.cisco.com (dhcp-171-68-20-80.cisco.com [171.68.20.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 9996368010F; Mon, 8 Feb 2016 17:33:23 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <5698B2AA.7060008@haw-hamburg.de>
Date: Mon, 08 Feb 2016 14:33:22 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E80FB83-1586-44D9-B8F3-17567B1F1F1C@cooperw.in>
References: <e41784d379854608bb9a6e027848cee3@HUB01.mailcluster.haw-hamburg.de> <5698B2AA.7060008@haw-hamburg.de>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/5txXtW-acwQiq41-fR6a2I7bv2A>
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:33:28 -0000
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 °
- [P2PSIP] AD evaluation: draft-ietf-p2psip-share-07 Alissa Cooper
- Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sha… Thomas C. Schmidt
- Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sha… Alissa Cooper
- Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sha… Thomas C. Schmidt
- Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sha… Thomas C. Schmidt
- Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sha… Alissa Cooper
- Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sha… Alissa Cooper