Re: [arch-d] Possible IAB Adoption of draft-kpw-iab-privacy-partitioning

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Wed, 14 December 2022 10:43 UTC

Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4922AC152703 for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Dec 2022 02:43:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQv6x60i3dFb for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Dec 2022 02:43:13 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16B6C1526FB for <architecture-discuss@ietf.org>; Wed, 14 Dec 2022 02:43:12 -0800 (PST)
Received: from lhrpeml500006.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NXBgg09Mdz6HJRn; Wed, 14 Dec 2022 18:39:27 +0800 (CST)
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Wed, 14 Dec 2022 10:43:09 +0000
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2375.034; Wed, 14 Dec 2022 10:43:09 +0000
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "iab@iab.org" <iab@iab.org>
Thread-Topic: [arch-d] Possible IAB Adoption of draft-kpw-iab-privacy-partitioning
Thread-Index: AQHY+enW0AcmIqiw1EmEIndbRN+Rba5tXYkw
Date: Wed, 14 Dec 2022 10:43:09 +0000
Message-ID: <5f58c5385a8941949fa7b221e1ed5192@huawei.com>
References: <166862348898.27211.16338265887689375983@ietfa.amsl.com>
In-Reply-To: <166862348898.27211.16338265887689375983@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.215.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/b2EmiVYUG_wDKZ-ezG50889dTQw>
Subject: Re: [arch-d] Possible IAB Adoption of draft-kpw-iab-privacy-partitioning
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2022 10:43:17 -0000

Hello, 

I have read very carefully draft-kpw-iab-privacy-partitioning-00 as it addresses a topic I am very interested in: privacy. 

I think it is a very good signal that the IAB is considering privacy as a topic it should work on. Nevertheless, this draft seems to only partially addresses the topic. 
The first thing that stroke me is that the document seems to assume that the protocol stack is starting at the transport layer. This is fine if it is clearly state upfront, which is not the case right now. The main manifestation of this fact is that protocols are discussed as if they were exchanging messages or establishing network flows. The packetization of both abstractions is not considered except at the very end of the document in section 7, while, as presented in several occasions in PEARG meetings, many attacks on the privacy of transport layer protocols are made through observation of packets processed at the network layer. Note that this vision is consistent with the protocol maintenance draft that was recently published and discussed. Maybe the authors of the draft don't consider that an attacker being able to perform timing attacks or packet correlation attacks belongs to the attacker they had in mind, but the attacker against which partitioning should be used to preserve privacy is not described. 

In the document, context isolation and partitioning are presented to protect a user's privacy, yet, traffic pattern correlation is overlooked as a possible threat. Indeed, the massive use of machine learning to improve traffic classification is a threat in the draft's model because traffic correlation is an indirect method that an attacker could use to link contexts together. The document would benefit from a discussion on the threat associated with the generalization of machine learning in traffic classification and network management.

Along the document, the authors mention the notion of proxying to protect a user's privacy. Proxying is presented as a means to separate contexts. In the literature, proxying is not the only strategy that has been investigated. Indeed, in several protocols presented in the academic world, source routing is used as an alternative to protect a packet sender's privacy. In Sphinx [1], for instance, a message source encodes a route in the header consisting in a list of intermediate nodes. Those intermediate nodes can then retrieve information that is very close to a segment to route the message to a next intermediate node. The document should discuss these alternatives.  

Even if we consider proxying, the document presents a system in which the proxy is chosen by the system, while in Tor, for instance, the set of proxies used to protect the user's privacy is determined at the source node. In a previous message [2], It was mentioned that users should be placed in control of decisions taken to protect their privacy, and I think that this is a key point to address. I don't think that policy or contractual agreements are sufficient to maintain a proper partition, and allowing a user to take informed decisions about the protection policy he/she adopts according to the threat he/she is willing to protect against is important. 
Both option should be discussed in the document.

Best regards,

Antoine Fressancourt

[1] Danezis, George, and Ian Goldberg. "Sphinx: A compact and provably secure mix format." 2009 30th IEEE Symposium on Security and Privacy. IEEE, 2009.
[2] https://mailarchive.ietf.org/arch/msg/architecture-discuss/CPd977gB__TjqQSzolvYbsBhutU/ 

-----Original Message-----
From: Architecture-discuss <architecture-discuss-bounces@ietf.org> On Behalf Of IAB Executive Administrative Manager
Sent: mercredi 16 novembre 2022 19:31
To: architecture-discuss@ietf.org
Subject: [arch-d] Possible IAB Adoption of draft-kpw-iab-privacy-partitioning

The IAB will discuss adoption of draft-kpw-iab-privacy-partitioning (Partitioning as an Architecture for Privacy) on the IAB stream at its meeting on 2022-12-07.

The draft can be found here: https://datatracker.ietf.org/doc/draft-kpw-iab-privacy-partitioning/

The agenda for the meeting will be posted 48 hours ahead of the meeting here: https://www.iab.org/wiki/index.php/Agenda

Feedback about this draft can be sent in response to this mail on architecture-discuss@ietf.org, or to the IAB directly at iab@iab.org.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss