Re: [lisp] [Ideas] 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: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669521342DF for <ietf@ietfa.amsl.com>; Wed, 11 Oct 2017 12:58:46 -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=unavailable 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 tK0kfsb9N3sc for <ietf@ietfa.amsl.com>; Wed, 11 Oct 2017 12:58:39 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 65D75132351 for <ietf@ietf.org>; Wed, 11 Oct 2017 12:58:37 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id a43so8865086qta.0 for <ietf@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=K/FgLx448E9px+XmAxottn57/5BJGPreEuSEvjha3pabfrE2Tw3YXGIOmDG0HutoZY u/AOYWBABAn1oW5d5BHwglRvlAA9Uc95TX9ggfqPbrdra2ubARCuJFqmvbaSX96cTWd+ dLMv9QGc65tk/Foi1j34zYLX/nvbtnH08I3HOj2iKBanVAZmiSkBvLLUV7n5XH7ZtzZt Nyjbl/I99D6nZkFzJHu1/AYwFhkjUikV8WVsINHdfL7l30+AAPO4qsVmG2GJwXzPV0vx RjfhfEVvW0oBIe9fu389m9DAxztet7ziRcSBv6Aj6jNJdsAuGyRG6Wo9kebq1qVnoV7V gMaQ==
X-Gm-Message-State: AMCzsaWsi8E+vima0PHBW1MTUlS15r2HjqT33lP+FkjX2CNt4NnZNWfI 8PoXCdKD8GTAZy2SdL3WwL2/5X+Sfi4v0PMkMZQzCA==
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>
Subject: Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)
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/ietf/SBEry9A3gr7PghhEp9qUyk-2mv4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 19:58:46 -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
> > >
> >
> >
>
>