Well, I'm not even going to justify ludicrous pedantry over 9 minutes with a response...moving on to potentially substantive issues...
>> 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. While your points below are worth considering, this particular point by itself is procedurally not relevant. You objected in the meeting, but despite this, consensus was to adopt the document (if the changes were made -- see below). You of course are still welcome to make the same objections on list, but it there is consensus, the fact you objected before the consensus call in the room and make the same objection now doesn't lack of consensus make. See http://tools.ietf.org/html/draft-dusseault-consensus-00 ... With those out of the way, the concern below is a potentially valid one: > 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: etc... What do others think of this concern? Do you feel that the document has been sufficiently modified that it reflects the intent of the WG desire to see it moving toward a tutorial? Obviously it is unreasonable to ask that it be perfect before it is adopted as WG item -- this isn't a WG last call, and WG items often are adopted while needing changes, corrections, additional work, etc.. That said, the question to the group is: 1) Do others agree with EKR that the document has not moved sufficiently in the direction requested in Stockholm and thus should NOT be adopted as a WG item or 2) Do people believe the changes request have more or less been made, and it should be adopted. David (as chair) > 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
