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