Hi Christian, Thank you for your comments to this document and for your support for adoption.
Haibin >-----Original Message----- >From: Schmidt, Christian 1. (NSN - DE/Munich) >[mailto:[email protected]] >Sent: Monday, October 26, 2009 6:25 PM >To: Xiao, Lin (NSN - CN/Beijing); ext Song Haibin; DRAGE, >Keith (Keith); Roni Even; Eric Rescorla; David A. Bryan >Cc: P2PSIP WG >Subject: RE: [P2PSIP] Consensus call on security draft > >I am in favour to adopt this version as WG item. > >BR >Christian Schmidt > > > >-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of ext Xiao, Lin (NSN - CN/Beijing) >Sent: Thursday, October 22, 2009 11:45 AM >To: ext Song Haibin; DRAGE, Keith (Keith); Roni Even; Eric >Rescorla; David A. Bryan >Cc: P2PSIP WG >Subject: Re: [P2PSIP] Consensus call on security draft > >Hi Haibin, > >Well done! I think this draft should be adopted as WG Item >now, as consensus got in IETF#75. Thanks. > > >Br >Xiao, Lin > >-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of ext Song Haibin >Sent: Saturday, October 10, 2009 5:27 PM >To: 'DRAGE, Keith (Keith)'; 'Roni Even'; 'Eric Rescorla'; 'David A. >Bryan' >Cc: 'P2PSIP WG' >Subject: Re: [P2PSIP] Consensus call on security draft > >Hi, > >Just updated the document a bit with removing RFC 2119 >requirement languages (no reference to RFC 2119 in this >document). The link for the new version is as below: > >http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-se >curity-ov >ervi >ew-01.txt > > >Thanks! >Haibin > > > >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On >>Behalf Of DRAGE, Keith (Keith) >>Sent: Saturday, October 10, 2009 7:51 AM >>To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >>Cc: 'P2PSIP WG' >>Subject: Re: [P2PSIP] Consensus call on security draft >> >>If I take the first two "must" usages in the document: >> >>"Thus, the architecture must consider this >> issue in the process of both enrollment and modification of P2PSIP >> resource (user) records in a P2PSIP overlay." >> >>"Nevertheless those >> attacks must be addressed by designers of service specific >protocols >> such as SIP [RFC3261]." >> >>Are either of these statements even relevant to a document of >tutorial, > >>i.e. educational nature, that the working group defined this to be. >> >>So essentially I am saying, irrespective of whether a reference to RFC >>2119 carries a normative nature or not, just changing the "MUST" to a >>"must" does not achieve the purpose you are trying to write this >>document for. >> >>The document, according to the scope defined by the working group, >>should be concentrating on the security issues, rather than writing >>statements about how the security should be addressed. >> >>regards >> >>Keith >> >>> -----Original Message----- >>> From: Roni Even [mailto:[email protected]] >>> Sent: Friday, October 09, 2009 9:40 PM >>> To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan' >>> Cc: 'P2PSIP WG' >>> Subject: RE: [P2PSIP] Consensus call on security draft >>> >>> Hi Keith, >>> My question was about what does it mean to have words like "must", >>> "should" >>> when you do not reference RFC 2119. >>> My take is that RFC 2119 defines the normative terminology >and if it >>> does not say that the document refers to RFC 2119 >>terminology than it >>> does not. >>> In this case there is no normative terms in a document. >>> I was also confused about the text in RFC 2119 and do not >understand >>> how is the force of the words changes based on the >requirement level >>> of the document . >>> This is why I claim that by my understanding of RFC 2119, >if you do >>> not reference it than there is no normative text in the >>document does >>> not matter if it lower or upper case. Also having the document as >>> informational weakens any strength of text in a document >>Regards Roni >>> Even >>> >>> > -----Original Message----- >>> > From: [email protected] [mailto:[email protected]] On >>> > Behalf Of DRAGE, Keith (Keith) >>> > Sent: Friday, October 09, 2009 1:31 PM >>> > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >>> > Cc: 'P2PSIP WG' >>> > Subject: Re: [P2PSIP] Consensus call on security draft >>> > >>> > My view is that using RFC 2119 words in a document even in >>> lower case >>> > is bad practice. It takes a slip of the editing pen for >>> them later to >>> > become uppercase. >>> > >>> > They also raise questions on review as to whether they >should have >>> > been upper case, at which point people promptly forget all >>previous >>> > decisions on the matter and make them upper case. >>> > >>> > Moreover, evaluating such current usage will undoubtedly make the >>> > document become clearer. Just changing upper case to lower >>> case will >>> > not result in a clear informational document. >>> > >>> > So I would support Eric in asking for a version of this >>> document that >>> > does not include any of the RFC 2119 language words, unless >>> of course >>> > there is agreement that normative material should later be >>included. >>> > (There are some exceptions to this, e.g. quotation from >>> another RFC). >>> > It appears to me that nobody is diputing that the current >>> consensus is >>> > that the document should be tutorial. >>> > >>> > regards >>> > >>> > Keith >>> > >>> > > -----Original Message----- >>> > > From: [email protected] >>> > > [mailto:[email protected]] On Behalf Of Roni Even >>> > > Sent: Thursday, October 08, 2009 6:53 PM >>> > > To: 'Eric Rescorla'; 'David A. Bryan' >>> > > Cc: 'P2PSIP WG' >>> > > Subject: Re: [P2PSIP] Consensus call on security draft >>> > > >>> > > Hi Eric, >>> > > About RFC 2119 language. >>> > > My understanding is that since there is no reference to RFC >>> > > 2119 which says that >>> > > >>> > > "In many standards track documents several words are used >>> to signify >>> > > the requirements in the specification. These words are often >>> > > capitalized. This document defines these words as >>> they should be >>> > > interpreted in IETF documents. Authors who follow these >>> > guidelines >>> > > should incorporate this phrase near the beginning of their >>> > > document: >>> > > >>> > > The key words "MUST", "MUST NOT", "REQUIRED", >>> "SHALL", "SHALL >>> > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>> > > "OPTIONAL" in this document are to be interpreted >>> as described >>> > > in >>> > > RFC 2119. >>> > > >>> > > Note that the force of these words is modified by the >>> requirement >>> > > level of the document in which they are used." >>> > > >>> > > >>> > > My understanding is that there is no normative text in >>> the document. >>> > > The meaning of "must" and "should" when not specified by >>RFC 2119 >>> > > does not make them normative. >>> > > Furthermore the document will be an Informational document >>> > > >>> > > Roni Even >>> > > >>> > > > -----Original Message----- >>> > > > From: [email protected] >>> [mailto:[email protected]] On >>> > > > Behalf Of Eric Rescorla >>> > > > Sent: Wednesday, October 07, 2009 10:39 PM >>> > > > To: David A. Bryan >>> > > > Cc: P2PSIP WG >>> > > > Subject: Re: [P2PSIP] Consensus call on security draft >>> > > > >>> > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: >>> > > > > >>> > > > > Eric, >>> > > > > >>> > > > > I don't agree this is premature in any way. >>> > > > > >>> > > > > We've allowed over a week on this topic. >>> > > > >>> > > > Well, David, since you insist: your mail asking for a >>> > > consensus call >>> > > > was sent at 12:25 EST on the 30th and stated: >>> > > > >>> > > > As the authors feel they have made the requested >>> > > changes, I'd like >>> > > > to >>> > > > ask folks on list to confirm this consensus. Please >>> > > send comments >>> > > > about adoption to the list, and we'll make a call after >>> > > there has >>> > > > been >>> > > > time to review and comment (at least a week). >>> > > > >>> > > > This mail declaring consensus was posted at 12:16 EST >>today, so >>> > > > the amount of time you have allowed, rather than being >>> "at least a >>> > week" >>> > > > is actually just under a week, so even by the most generous >>> > > > interpretation of the situation, this is slightly >>> premature. Given >>> > > > that you did not provide any real deadline, it is quite >>> premature. >>> > > > >>> > > > >>> > > > > You never posted saying you >>> > > > > were reviewing, you have made no comments on list about the >>> > > > > draft since Stockholm. Bruce started a thread on >the previous >>> > > version way >>> > > > > back on July 25th, and you didn't comment. >>> > > > >>> > > > Because I had already made comments on the previous version >>> > > during the >>> > > > meeting. >>> > > > >>> > > > >>> > > > > Are there others besides yourself (and Cullen)? If so, >>> > > speak up now. >>> > > > > Otherwise, we had consensus in the room and allowed a >>> reasonable >>> > > > > time for comments on list. >>> > > > >>> > > > While I agree, we had consensus in the room, this document >>> > > does not in >>> > > > fact live up to that consensus. I've just listened to >>> the relevant >>> > > > section of the WG meeting and it was quite clear that >>> what the WG >>> > > > hummed for was as a general tutorial/overview of security >>> > > in the P2P >>> > > > space. However, it was extremely clear that this >>> document was to >>> > > > be non-normative, as stated by Roni, Brian, and myself. >>> > > Moreover, this is >>> > > > confirmed by Dan's message when this document was posted: >>> > > > >>> > > > At IETF 75, we were given the direction to remove the >>> RFC 2119 >>> > > > language from >>> > > > the document and move it from being a normative doc >>> to a purely >>> > > > informational doc. I have now started this and made >>> a number of >>> > > > other >>> > > > changes, including most notably the name change from >>> > > > "p2psip-security-requirements" to >"p2psip-security-overview": >>> > > > >>> > > > While the 2119 language was removed, which is a start (and >>> > > I realize I >>> > > > focused on this over Jabber, but limited bandwidth is >>a cost of >>> > > > not being in the room), the document is full of >normative text, >>> > > albeit not >>> > > > rendered in upper case. I count 23 separate instances >>> of the word >>> > > > "must" and "30" of the word "should". For example: >>> > > > >>> > > > S 5.1. >>> > > > protected against attacks(such as Man-in-the-Middle). >>> > > In order to >>> > > > establish the identity trust association, nodes must >>> > authenticate >>> > > > each other with e.g. TLS and DTLS. If transport >>> > > service security >>> > > > is >>> > > > provided, we can prevent nodes without valid identities to >>> > > > participate in the overlay. This layer must provides >>> > > reliable and >>> > > > secure hop-by-hop transport service for the P2P >>> overlay. This >>> > > > alone, >>> > > > though, is not enough to secure the P2P system. >>> > > > >>> > > > S 8.1. >>> > > > The user wants available and reliable service that >>> enables him >>> > to >>> > > > interact with other users and resources in a secure way. >>> > > This means >>> > > > that the P2PSIP system must provide: >>> > > > >>> > > > Worse yet, some of these actually contradict design >>> decisions that >>> > > > have already been made in RELOAD: >>> > > > >>> > > > S 8.2.11. >>> > > > The security of P2PSIP systems must guarantee privacy of >>> > > the P2PSIP >>> > > > network participants. The P2PSIP security should allow >>> > > the users >>> > > > and >>> > > > P2PSIP network entities to indicate which other >>> users or P2PSIP >>> > > > network entities can retrieve, modify, and delete >>> data stored in >>> > > > their P2PSIP resource (user) records. The owner of >>a P2PSIP >>> > > > resource >>> > > > (user) record should be able to limit the access to his >>> > > own resource >>> > > > (user) records, and this feature should be enforced >>> by the P2P >>> > > > network. >>> > > > >>> > > > This is a particularly egregious case since there is no known >>> > > > mechanism for securely providing read-level access in a P2P >>> > > > storage network, which is why RELOAD assumes that data >>> > > confidentiality will be >>> > > > solved by encryption rather than access control. >>> > > > >>> > > > This material is not even remotely tutorial in nature. >>> Quite the >>> > > > contrary, it is requirements text, regardless of the >fact that >>> > > > it's not capitalized. In order for this document to >>conform to >>> > > > the consensus in Stockholm, then, all this language >needs to be >>> > > removed. >>> > > > If the authors/WG feel it is important, it might be >>> replaced with >>> > > > descriptions of the security consequences of various design >>> > > choices. >>> > > > However, as it stands, no I don't agree that this document >>> > > either is >>> > > > acceptable or that it has consensus: the consensus in >>Stockholm >>> > > > was contingent on changes that have not been made, and the >>> > > > overwhelming silence on the mailing list after this >>revision is >>> > > > not at >>> > > all the same >>> > > > as consensus. >>> > > > >>> > > > -Ekr >>> > > > _______________________________________________ >>> > > > P2PSIP mailing list >>> > > > [email protected] >>> > > > https://www.ietf.org/mailman/listinfo/p2psip >>> > > > >>> > > > __________ Information from ESET NOD32 Antivirus, >>> version of virus >>> > > > signature database 4488 (20091007) __________ >>> > > > >>> > > > The message was checked by ESET NOD32 Antivirus. >>> > > > >>> > > > http://www.eset.com >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > __________ Information from ESET NOD32 Antivirus, >>> version of virus >>> > > > signature database 4488 (20091007) __________ >>> > > > >>> > > > The message was checked by ESET NOD32 Antivirus. >>> > > > >>> > > > http://www.eset.com >>> > > > >>> > > > >>> > > > __________ Information from ESET NOD32 Antivirus, >>> version of virus >>> > > > signature database 4491 (20091008) __________ >>> > > > >>> > > > The message was checked by ESET NOD32 Antivirus. >>> > > > >>> > > > http://www.eset.com >>> > > > >>> > > >>> > > >>> > > __________ Information from ESET NOD32 Antivirus, version >>> of virus >>> > > signature database 4491 (20091008) __________ >>> > > >>> > > The message was checked by ESET NOD32 Antivirus. >>> > > >>> > > http://www.eset.com >>> > > >>> > > >>> > > _______________________________________________ >>> > > P2PSIP mailing list >>> > > [email protected] >>> > > https://www.ietf.org/mailman/listinfo/p2psip >>> > > >>> > _______________________________________________ >>> > P2PSIP mailing list >>> > [email protected] >>> > https://www.ietf.org/mailman/listinfo/p2psip >>> > >>> > __________ Information from ESET NOD32 Antivirus, version >of virus >>> > signature database 4494 (20091009) __________ >>> > >>> > The message was checked by ESET NOD32 Antivirus. >>> > >>> > http://www.eset.com >>> > >>> > >>> > >>> > >>> > __________ Information from ESET NOD32 Antivirus, version >of virus >>> > signature database 4494 (20091009) __________ >>> > >>> > The message was checked by ESET NOD32 Antivirus. >>> > >>> > http://www.eset.com >>> > >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4494 (20091009) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >>_______________________________________________ >>P2PSIP mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/p2psip >> > >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
