Re: [P2PSIP] Mirja Kühlewind's No Objection on draft-ietf-p2psip-share-09: (with COMMENT)

"Thomas C. Schmidt" <t.schmidt@haw-hamburg.de> Mon, 31 October 2016 14:38 UTC

Return-Path: <t.schmidt@haw-hamburg.de>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87712950C; Mon, 31 Oct 2016 07:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_xDzpRxcMsF; Mon, 31 Oct 2016 07:38:01 -0700 (PDT)
Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB4912960B; Mon, 31 Oct 2016 07:37:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.31,575,1473112800"; d="scan'208";a="44125159"
Received: from post.haw-hamburg.de (HELO HUB02.mailcluster.haw-hamburg.de) ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2016 15:37:52 +0100
Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Oct 2016 15:37:51 +0100
Received: from [192.168.178.122] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Oct 2016 15:37:51 +0100
To: Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
References: <02239df0a78b4b218f58e98d27f23405@HUB02.mailcluster.haw-hamburg.de>
From: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Message-ID: <b15c05cd-847e-0e1e-e9c3-a395a8facc53@haw-hamburg.de>
Date: Mon, 31 Oct 2016 15:37:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <02239df0a78b4b218f58e98d27f23405@HUB02.mailcluster.haw-hamburg.de>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [141.22.250.35]
Archived-At: <https://mailarchive.ietf.org/arch/msg/p2psip/JR2nR3yVBlHaz7xxm37hp63mkvo>
Cc: "draft-ietf-p2psip-share@ietf.org" <draft-ietf-p2psip-share@ietf.org>, "marc@petit-huguenin.org" <marc@petit-huguenin.org>, "p2psip@ietf.org" <p2psip@ietf.org>, "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>
Subject: Re: [P2PSIP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-p2psip-share-09=3A_=28with_COMMENT=29?=
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2016 14:38:05 -0000

Hi Mirja,

you are right in the sense that (a) if all previous evaluations have 
been performed without a failure, and (b) if no revocation occurred (or 
(c) a previous revocation has cleaned up all further delegation 
entries), then the write procedure can rely on the single delegation 
entry that matches the current user name of the writer.

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.

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.

That's why it's like that.

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 °