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
