Re: [Ideas] Privacy benefits of Identity Was: Re: Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

Tom Herbert <tom@herbertland.com> Wed, 13 September 2017 23:53 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0A126B7E for <ideas@ietfa.amsl.com>; Wed, 13 Sep 2017 16:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 pQesc-Bz5och for <ideas@ietfa.amsl.com>; Wed, 13 Sep 2017 16:53:13 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9C5126B71 for <ideas@ietf.org>; Wed, 13 Sep 2017 16:53:13 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id t46so4229638qtj.2 for <ideas@ietf.org>; Wed, 13 Sep 2017 16:53:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xDhBHtXR33h3VosHW6TXIR3sp3sJUrgwLD9RWr8g0J0=; b=1veMxbeXSuV47BgUtvi9v4lgr7efe9WB5x2guHD1tgxIuwaAx3HnbknqpXOrjoPsm0 7ZPcTgWCy0CBksIK9GyfWH1mGWjxb3JdwfG/B3gLPhYpqhffHwyVEvvZBNDqnpxKklRG qrbcSZfKIZtmfKn3KY9UNkw/ecEX/OrgMOiF2CFkMFqj+DXkg6Wtq7Irnap1v/W7uZ6P 8Tr3LJkFCnjltbQI1pzOGJlvLb3AKWT2628WIgvSCAAIHO0Oc1yeQPUv/kez7d2boH8f pClz4Pa45aPiVzXUA/FsFZzwR+tVXSM6jJIdRN/n7olLdtVhdO87lLc/0iRASAHvp5Xd cQOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xDhBHtXR33h3VosHW6TXIR3sp3sJUrgwLD9RWr8g0J0=; b=Gfp8/gH5k6hD4zEYVIWd7UDHNEG9XdWIVJZmLDBLI/HCbFTqraHxHGIp0YE6/NJyJN ZOpg1slaRWKFkbPYY1vHvfuWQKyn8YjNe9xhxTnhChjhQ2eZ/3taO4u2rYi5BcvOanzn dXe5jBg33dNxButa3jkShkCYzBqkaIZecIG1e5qlCJdZH2LWRVkbJ40y7o1FMW3gmuFp 3s8Y7F+v8iH67+5xWyhcpPq0u9h0ZQDwcDCiUlm0E5gz0h9DmQlc+ejhpBB/P0TEo8Bq fQogOhr/ziQ3VnmRfIDtvnbejSsADG5x2TcK5HYh9PA4OWjMiijsAAuVI8jpVrNLHgJa 1TJQ==
X-Gm-Message-State: AHPjjUhXSRIsY+WjTYGXUj6scrUHOT6ms09ZhLajkeO0fgKyujbbLDL1 kTOX6ZRm7YSMSFt1cFaEB7ScNdXKN8iIV77ziZ3lYA==
X-Google-Smtp-Source: AOwi7QCxIy5SBlVEWJhca9ysDypfBLAaPJ00H8z0WRPu4Yw9jBATQIkCuOKTZP/43HWKd/Pw6tJeTyG7qIUPNQ0xQ6o=
X-Received: by 10.237.56.167 with SMTP id k36mr29966538qte.286.1505346792353; Wed, 13 Sep 2017 16:53:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.61.196 with HTTP; Wed, 13 Sep 2017 16:53:11 -0700 (PDT)
In-Reply-To: <25B4902B1192E84696414485F572685401A5ED17@SJCEML701-CHM.china.huawei.com>
References: <CALx6S37qkf9GuH5_G6Y+ZTppjLZTG+wn+i5RcLQ_rDk3eLtLkQ@mail.gmail.com> <25B4902B1192E84696414485F572685401A5ED17@SJCEML701-CHM.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 13 Sep 2017 16:53:11 -0700
Message-ID: <CALx6S34WkO68ifV4E5Mnj2dyqagd7UR0OmoqGWcczPTZN+c7Cw@mail.gmail.com>
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: "ideas@ietf.org" <ideas@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/zOAgDfrFtkhYrIUG8n2tJjX2xUw>
Subject: Re: [Ideas] Privacy benefits of Identity Was: Re: Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Sep 2017 23:53:15 -0000

On Wed, Sep 13, 2017 at 4:23 PM, Uma Chunduri <uma.chunduri@huawei.com> wrote:
>
>         >"b.  Data plane anonymization allows entities to communicate anonymously from the outside observers.  Identity provides deanonymization for various data plane ephemeral Identifiers,
>                 >if required, and enables resolution of which entity is behind these identifiers for legitimate users (entities itself in some cases)."
>
>         >Data plane anonymization exists by virtue of providing a hosts multiple addresses or identifiers and not putting anything in a packets that allow cross correlation. Identity is not required to achieve anonymization.
>         >Per the text, identity provides for deanonymization which seems to contradict the goal of anonymization. The text also states that deanonymization would be done "if required".
>
>                 >So my question is under what circumstances would deanonymization be required?
>
> [Uma]: Great question.
> It's possible,  in case if receiving entity of the data traffic want's to control which entities it wants to receive the traffic from (or prioritize them).
> A simple example could be a connected vehicular node/IoT may want to receive traffic from only certain entities (dealer or manufacturer or xyz)  updates and their long-lived ID's are
> used in the local policy at the receiving end. If one of the legit sending entity uses anonymized identifier; receiving entity might want to de-anonymize  the same before accepting the traffic -  to see if it matches to the corresponding long-lived Identifier it set the policy for.
>

Uma,

That implies addresses are used as security mechanism, but really
there's no security in addresses. They can too easily be spoofed. For
security, there's are already existing mechanisms for authentication
that are much stronger than any address verification.

As for the question about changing long lived identifiers, it seems
like that could be accomplished as a protocol between two endpoints.
For instance if endpoint A and endpoint B want to communicate they
could exchange a list of addresses they should consider to be
equivalent through a secure side channel. This doesn't require any
interaction with the network infrastructure other than getting
multiple address assignments. MP-TCP effectively allows this and is
even compatible with existing firewalls.

Thanks for the discussion,
Tom