Re: [P2PSIP] Consensus call on security draft

[Song Haibin <melodysong at huawei.com>]

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:christian.1.schmidt at nsn.com] 
>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: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] 
>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: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] 
>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: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] 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:Even.roni at huawei.com]
>>> 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: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] 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: p2psip-bounces at ietf.org
>>> > > [mailto:p2psip-bounces at ietf.org] 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: p2psip-bounces at ietf.org
>>> [mailto:p2psip-bounces at ietf.org] 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
>>> > > > P2PSIP at ietf.org
>>> > > > 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
>>> > > P2PSIP at ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/p2psip
>>> > >
>>> > _______________________________________________
>>> > P2PSIP mailing list
>>> > P2PSIP at ietf.org
>>> > 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
>>P2PSIP at ietf.org
>>https://www.ietf.org/mailman/listinfo/p2psip
>>
>
>_______________________________________________
>P2PSIP mailing list
>P2PSIP at ietf.org
>https://www.ietf.org/mailman/listinfo/p2psip
>_______________________________________________
>P2PSIP mailing list
>P2PSIP at ietf.org
>https://www.ietf.org/mailman/listinfo/p2psip
>