[icnrg] FW: [irsg] Tags changed for draft-irtf-icnrg-challenges

Dirk Kutscher <Dirk.Kutscher@neclab.eu> Tue, 08 March 2016 17:06 UTC

Return-Path: <Dirk.Kutscher@neclab.eu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144FF12D87A for <icnrg@ietfa.amsl.com>; Tue, 8 Mar 2016 09:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNmJ7XiRf2gN for <icnrg@ietfa.amsl.com>; Tue, 8 Mar 2016 09:06:22 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E8C12D85B for <icnrg@irtf.org>; Tue, 8 Mar 2016 09:05:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 82EB910C689; Tue, 8 Mar 2016 18:05:40 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhOCc6HQ1v_e; Tue, 8 Mar 2016 18:05:40 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 4BCEC10C677; Tue, 8 Mar 2016 18:05:36 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.191]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 8 Mar 2016 18:05:36 +0100
From: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
To: "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: [irsg] Tags changed for draft-irtf-icnrg-challenges
Thread-Index: AQHRbuQ70JcAFUEF+E+KZBnxU2C2kp9I6LOAgAQ9hoCAAq3SEA==
Date: Tue, 08 Mar 2016 17:05:36 +0000
Message-ID: <82AB329A76E2484D934BBCA77E9F5249A9FA4A46@PALLENE.office.hd>
References: <20160224091741.18513.63318.idtracker@ietfa.amsl.com> <26813B0B-CF96-4C7A-B341-3E1A57CFFA06@ericsson.com> <068DD1FC-8E3F-4A4E-8023-C7C5C79B4D83@netapp.com> <44226C19-93CF-4D84-BFBE-017070CC3EA6@vigilsec.com>
In-Reply-To: <44226C19-93CF-4D84-BFBE-017070CC3EA6@vigilsec.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.2.102]
Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A9FA4A46PALLENEofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/icnrg/4vEtgarxv5pS8l4SzTLa6GWRvzA>
Cc: "Russ Housley (housley@vigilsec.com)" <housley@vigilsec.com>
Subject: [icnrg] FW: [irsg] Tags changed for draft-irtf-icnrg-challenges
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 17:06:30 -0000

Hi,

we got some additional comments on the challenges draft - see below (thanks, Russ).

My view on these comments is as follows (others, please share your view):

Regarding "secret key": yes, indeed - that should be fixed.

Regarding versions: We wanted to mention the general challenge in ICN (and immutable name/data bindings). For the discussion here, we thought that would imply "newer and older versions", so did not want to mention that explicitly to keep the level of detail balanced - let us know if you think that is critical to mention.

Regarding access control delegation: Yes, currency and consistency of access control lists could be a problem. In the referenced paper, I think the assumption is to have a single access control instance.  Perhaps we can be more specific here.

Regarding revocation, yes, that's a problem. It's described to some extent in the referenced paper (https://www.ietf.org/mail-archive/web/icnrg/current/pdf9_JIQ5GBeS.pdf). We could perhaps mention this explicitly, as a third challenge, in the draft. And yes, that's a general problem for ICN with a PKI-like service.

Regarding RFC 7696, yes, it applies of course, but since we are not really formulating implementation requirements here, we did not reference it.

Regarding the privacy question, I would generalize that in saying that there is a general tradeoff between enabling "useful network services" (by leveraging some visibility of names or other request properties) and privacy risks (for example by allowing for correlation of requests to user identity, location etc.).  The key privacy protection challenge is associated to name visibility, which we described in section 4.1.  We can discuss to what extent we want to explicitly describe the correlation options. We are planning to discuss this in more detail in a dedicated draft in ICNRG.

Cheers,
Dirk




From: irsg [mailto:irsg-bounces@irtf.org] On Behalf Of Russ Housley
Sent: Montag, 7. März 2016 01:44
To: Lars Eggert; Börje Ohlman
Cc: Internet Research Steering Group
Subject: Re: [irsg] Tags changed for draft-irtf-icnrg-challenges

As requested, I read the document.  I have a few comments.

When the document uses "secret key", it ought to use "private key".  This makes it clear that public/private key pairs are being used.

When talking about named versions, the document says: "and a way for requestors to learn about versions".  I think it is important to be able to learn about newer and older versions.  Sometimes it is important to be able to see the differences over time.

When talking about access-control-delegation, there are additional challenges associated with ensuring availability.  If the access list is available form many places, it creates a synchronization problem when the list is updated.

When talking about using encryption to implement access control, there is an additional concern.  Once the key is obtained, how can the publisher revoke future access?  Maybe this concern applies to other mechanisms too.

When talking about cryptographic robustness, I think RFC 7696 applies here too.

Does the combination of mobility and wireless access create an additional privacy research topic?  Does tracking which documents are accessed from various locations lead to a new type of traffic analysis?

Russ



On Mar 4, 2016, at 2:58 AM, Eggert, Lars wrote:


IRSG, please review and ballot.

On 2016-02-24, at 10:25, Börje Ohlman <borje.ohlman@ericsson.com<mailto:borje.ohlman@ericsson.com>> wrote:

I hereby initiate the IRSG poll for this document.

Börje



Begin forwarded message:

From: IETF Secretariat <ietf-secretariat-reply@ietf.org<mailto:ietf-secretariat-reply@ietf.org>>
Subject: Tags changed for draft-irtf-icnrg-challenges
Date: 24 februari 2016 10:17:41 CET
To: <draft-irtf-icnrg-challenges@ietf.org<mailto:draft-irtf-icnrg-challenges@ietf.org>>, <Borje.Ohlman@ericsson.com<mailto:Borje.Ohlman@ericsson.com>>, <icnrg-chairs@ietf.org<mailto:icnrg-chairs@ietf.org>>


The tags on draft-irtf-icnrg-challenges have been changed by Borje
Ohlman:
https://datatracker.ietf.org/doc/draft-irtf-icnrg-challenges/


Tag "AD Followup" cleared.


Comment:
The document have been updated after a first IRSG review and been
subjected to a new RG last call which did not result in  any comments.
So we now believe the document is ready for the IRSG poll.