Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)

Eric Rescorla <ekr@rtfm.com> Wed, 11 October 2017 19:58 UTC

Return-Path: <ekr@rtfm.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 4CB641342DB for <ideas@ietfa.amsl.com>; Wed, 11 Oct 2017 12:58:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 CkcTNsExpyAc for <ideas@ietfa.amsl.com>; Wed, 11 Oct 2017 12:58:39 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 65DE613307B for <ideas@ietf.org>; Wed, 11 Oct 2017 12:58:37 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id p1so8825586qtg.2 for <ideas@ietf.org>; Wed, 11 Oct 2017 12:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l70Gu05Ng6IDXOQ9t7Dw+emfQY83Pr+3ePuITM/8kQ8=; b=gmqTKbrtN5LZ31Zb9fRcfrynkXQbmL0dAkxkaD16DCGqn2afjn7b2x77QTkepanXe4 IWbhvQO/MNBe+BeVrGC6vTNIZ6XRq21i+KuO1H/oBBp4wmZoRepTQzUZnvvRReaB+v/0 D9kblX1rgl0plxOgnQsku7N5I1jHJTPjzvieCepk0fO+6qQyjtjb+Uqi8M1UyIqXQ1lt e1N9Rw/m5x5mCRDtQA115vsFVN7iaPm4Y/5QKwYKEkxELpP22zjjEEdLHW/XPs0s6fic 97/oZRjjMHx68DqfNnEzeQSLQS46xhNPRqBzzdEFL0WU4G+Onc09RGVG/bnWjLpcDSBd dSgA==
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; bh=l70Gu05Ng6IDXOQ9t7Dw+emfQY83Pr+3ePuITM/8kQ8=; b=NoYlceCjeWyn8J1y7D0TgXdaR2T1uq8Gt8lfxSgX6w7wVdD/wbXXHn5r5XMqm5+u+k 2SQlG6gmsRo2Qlsy8QtZa0I8G8wGjLbm8g0wouy1neYorQNcbwnA9ZOm8dVZXLKSaka6 rGeOQdxawH2fdyNs2wYJ1fIc3X19xXKjVmu63+wYN08Zkzj3jJeqaT6uIUccT+QOyIBs ZY31jJqQ+9idTqI5r+3oKH7uJM5cxlk0q+733Q4g1Kig1if9imAZhEQJeGXOnxK5IRAy Ahe4672cPuj8xXlkqxrvhZXSqw6NSFbwdAj5aRtQLUcyfoSD4e62gNeXYLVrz6Vnietd vQQA==
X-Gm-Message-State: AMCzsaX1mEGfJPtSC2OxbZX5Hihi1Glmn4dJccp/JMqr/O5Los33FXYo GF38RlRTbjSfBp8qxtj+CCHVofaWECn0LQyZVHl6Hw==
X-Google-Smtp-Source: AOwi7QCeKPm9S1Ah83s+nDSkDjSd1vOks1XlbguHucB/+kRmy3ekBQb8JhlpcOirwqJAl++NWqwerEu3s2N8lGANSkQ=
X-Received: by 10.37.51.68 with SMTP id z65mr445311ybz.353.1507751916477; Wed, 11 Oct 2017 12:58:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 11 Oct 2017 12:57:55 -0700 (PDT)
In-Reply-To: <C570D442-1D74-42FD-8DB6-1B548A96162E@gmail.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <CAMm+Lwg61PGrcmu=-e8ciD6Q+XmEaWWDys4g2M657VOjWmaGcg@mail.gmail.com> <CALx6S370-TuoUicWep5vV2NjLPS4d-HP1qVxW_nGrxhBLw6Eug@mail.gmail.com> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <dd2c3bd5-dd37-109b-2e81-0327db4daa09@cs.tcd.ie> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <fa644cc2-161f-8884-3445-2b50d2c2ad23@htt-consult.com> <cf2ca920-f2d2-b65e-05eb-ebe3c30b76d1@huitema.net> <CAG-CQxrdS9L+2+bN=1NcPGuztn4U4OwSWUiNaVcS9Bsm2mtpfA@mail.gmail.com> <b18459d1-7ce1-b83d-787d-9066267d584b@huitema.net> <17BE9E1D-120B-4508-B765-3799134FD708@gmail.com> <CABcZeBPngxTYDHA0T_eeexUyd=yKObADgKz75SNjbWNVoWLfdQ@mail.gmail.com> <C570D442-1D74-42FD-8DB6-1B548A96162E@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 11 Oct 2017 12:57:55 -0700
Message-ID: <CABcZeBPn5PTPhERjU=pW4Mp8KtkOxy71ntymunHgvEEvOMFTzg@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, "ietf@ietf.org" <ietf@ietf.org>, "ideas@ietf.org" <ideas@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="001a1148aa62643246055b4ad9cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/xpNbp_K-xHAAtmbb5QQBi9IXtvE>
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)
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, 11 Oct 2017 19:58:45 -0000

On Wed, Oct 11, 2017 at 12:51 PM, Dino Farinacci <farinacci@gmail.com>;
wrote:

> > On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <farinacci@gmail.com>;
> wrote:
> > Let me ask for your opinion Christian (or anyone else for that matter).
> If a device is assigned a private/public key-pair and the identifier for
> the device is a hash of the public-key, is the identifier private?
> >
> >
> > I can't answer this in isolation. Does the identifier show up on the
> wire? If so, then totally.
>
> When the payload is encrypted, it does not.


Are the handshakes that establish the cryptographic keys used to encrypt
the payload themselves encrypted? If it's IKE, the answer is probably yes,
but if not, I don't know.


So let me ask you these follow-up questions:
>
> (1) If a host sources a packet with its identifier in one VM and an
> encapsulator in another VM (in the same physical system) encapsulates the
> packet but encrypts the payload before encapsulation, has the identifier
> remain private?
>
> (2) If in (1), the packet is decapsulated by an intermmediate point, and
> then reencapsulated but the packet is encrypted with a new session key
> (from a new ECDH exchange) to the destination, has the identifier remained
> private?
>

Generally, I don't tend to think of things as being "private" or
"non-private". Rather we talk about who has a given capability or piece of
information. I think it's clear that in these cases the identifier was
available to the machine doing the deencapsulation/reencapsulation.
Obviously, that's worse for privacy than having it not have that
information. How much worse depends on a lot of factors.

In this particular, work, however, it seems like the privacy concerns are
about:

1. Whether the ID mapping systems reveal who is talking to who.
2. Whether this creates persistent identifiers that would otherwise be
destroyed when people changed their location

Maybe Christian and Stephen would like to say more about their concerns
-Ekr

>
> Dino
>
> >
> > -Ekr
> >
> >
> > Is the identifier trackable even when its network location is not
> generally known, not advertised publicly, and possibly changing frequently?
> >
> > Dino
> >
> > > On Oct 11, 2017, at 12:34 PM, Christian Huitema <huitema@huitema.net>;
> wrote:
> > >
> > > On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:
> > >> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
> > >>
> > >>
> > >> The identity of the device is just adding a lever of identifier which
> effectively allows authentication to modify the identifiers used by that
> device but also what the users of these identifiers can look up. If we had
> used "user of identifier" it would have been misconstrued for humans. So
> damn if you do and damn if you don't ...
> > >>
> > >> We are open for discussions anytime.
> > >>
> > >
> > > Some thing you should be hearing is that "long term identity of
> device" has almost the same privacy properties as "long term identity of
> the device's owner". You may think that identifying a random piece of
> hardware is no big deal, but it turns out that the network activity and
> network locations of that piece of hardware can be associated to those of
> its human owner. So you need the same kind of protection for these device
> identifiers as for human identifiers.
> > > --
> > > Christian Huitema
> > >
> >
> >
>
>