Hi, that means in the cached case where you know for sure there have been no modification (because it a non-modifiable copy) you don’t do the check, but only if you are basically not sure if there has been a modification in the mean time. That makes more sense. Probably worth stating this more explicitly in the doc.
Mirja > Am 04.11.2016 um 19:35 schrieb Thomas C. Schmidt <[email protected]>: > > Hi Mirja, > > On 04.11.2016 11:20, Mirja Kuehlewind (IETF) wrote: > >>> >>> However, this includes several "ifs". For instance, if cleanup of the >>> delegation list has not been completed at the time of granting write >>> access, errors in the trust chain may occur. This could introduce unwanted >>> attack surface. >> >> Could you document this attack surface in the doc…? >> > > Mhmm, if complete validation is performed (as requested by the document), the > attack surface is not there. As pointed out in 6.2, valid revocation is a > single operation. Otherwise there would be probably a lengthy discussion on > "how can I disturb a peer" (DoS, malicious requests, ...) > > We would rather be robust and skip this set of options ;) > >>> >>> Our rationale behind designing this complete, self-contained procedure was >>> (a) writing an ACL list is not a frequent operation (so complexity is not >>> the major concern), and (b) keeping all operations simple, robust, and of >>> minimal dependence w.r.t. each other. >> >> Don’t you have to do the check every time you check write access for a >> shared resource? That can be much more often. >> > As of Section 6.5, an accessing peer can cache (the list and the validation). > So it can memorize previous checks and doesn't have to do them over an over > again. However, initially and in the case of actual writing the shared > resource, we want a full verification. > > Cheers, > Thomas > > >>> On 31.10.2016 15:06, Mirja Kuehlewind wrote: >>>> Mirja Kühlewind has entered the following ballot position for >>>> draft-ietf-p2psip-share-09: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Quick questions on sec 6.3. (Validating Write Access through an ACL): >>>> Do I really need to validate the authorization chain in the ACL every >>>> time I give access to a resource? Wouldn't I rather validate the ACL when >>>> it's modified and then simply assume that it is sufficient that I have an >>>> entry in the ACL to provide access? >>>> >>> >>> -- >>> >>> Prof. Dr. Thomas C. Schmidt >>> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >>> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° >>> > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
