Re: Address privacy

Tom Herbert <tom@herbertland.com> Wed, 29 January 2020 00:17 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E351200EF for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 16:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 hyL6UXUbznDY for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 16:17:17 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 893261200B7 for <ipv6@ietf.org>; Tue, 28 Jan 2020 16:17:17 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id cy15so16742200edb.4 for <ipv6@ietf.org>; Tue, 28 Jan 2020 16:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/7qC9wUB4KpUcgbBzcebf/NPYkAfsu11AYUPLFZKXhc=; b=pf0b3LIJmREqhgDBtA/i6EsyIFv5nZ1m+IzWdgA/q8cD82WPL6u0/pJXZI+iCZY2Kx 1Gfwggndt4fwWHQRTHhvMt0KRkqz7iaYBsgmlK3626nNd8fdxxGXL/kzGthQCbYNz3+G KRGneGRsG0TMM4JhotG+Zdyg+oR1RNpOHjzKLZqnPdH5MtNR3uTYOplRM8xzBdpBA6Ei olt28TPvh2GRsBkwBuph9dZw9mlLR+LBm8VLG1OVm8980nuZ6B6b/eup8nlwIvwZLa9L mkQ1upouB6MxMKnvt4WeK/8o2cnaq0nMTW0W08FEXLjIJdUktwsY3RnTtl6PJoWf8eWC 8k0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/7qC9wUB4KpUcgbBzcebf/NPYkAfsu11AYUPLFZKXhc=; b=J0AwJ0vUeaDr11OGeUQjhOlL5j0OhVaA4TSyt8S2u+7uKIwn7EFAHjNKk4Uj5f02c2 94ZENKvsbn9qIb2fqoBzl9vY5UQ9W8VaxF+FSfjqOsxuWcDpmUoR/7chT0/KoZWvKKhl PdbMg+X0V65aD/E2eHJFXAZ9R3XRVVdwaOTIhtmOgH8LAzeUHpE7lyWO0p+RE9D5JC03 gtgUlwy8fS7datzpfztSiKWFvfNyqUQI5geUn2B8Ee4AX4NffVJI39HHoZiTYZP44Y7w VHBvavhAbRzKhZ0+gWibU8Lbm3wbdviOAYSBSZHDDYw1TCkJDK1UX4vQbwh8h0VCzUb9 HlHg==
X-Gm-Message-State: APjAAAV7+HzoauOtSjVAFaiFn2slZ5xJRRYjIVYT/BA5vZ4eRlc86TvO 761PMtANGukwIdxVJg/Iuw/WiMsW3tuSItvTBg4H1gi1
X-Google-Smtp-Source: APXvYqy0IlUfm8J5DFDlFH0y66EOp5lYH5oT38Wr5HJ8+oWopgT/Yb0rR8/negC0rrKMrwIHYH0Y3LlR+FFqteNScgA=
X-Received: by 2002:a50:fb08:: with SMTP id d8mr5569598edq.79.1580257035962; Tue, 28 Jan 2020 16:17:15 -0800 (PST)
MIME-Version: 1.0
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <1962.1579823388@localhost> <f83ab037-9125-bb74-dbac-68850aeb1020@huitema.net> <CBB23ABE-A7A3-4208-873C-E47EE063E34B@fugue.com> <11855.1579980079@localhost> <CALx6S36V_VjaxhELYcsgDYLWsCkj20p6gtiY9T9Q=9-9Oibyjw@mail.gmail.com> <32626.1580060558@localhost> <CALx6S37prWACD0jv9c-XHD-JtPqZAcgeT2Ax0EZHkiQaDR4t=g@mail.gmail.com> <419b7c7a-e364-7951-5a44-6c39e1da65fb@joelhalpern.com> <CALx6S36802oDaEgojAPq2c6hM_s1BayidXPh1Sc6RZmZa9UHpQ@mail.gmail.com> <6c5ba72d-9289-90ba-a1c9-2307ed29a4da@foobar.org> <a98bf2ab-32e7-459b-14d2-5e0e1c65a229@si6networks.com> <CALx6S36J5TPnXJQyMW2NUbQV6KL_oqUQ01m+BEzBJ+xcHpmQWw@mail.gmail.com> <bc0d1eb8-2301-224d-dc33-19f6a60e593e@si6networks.com> <CALx6S34i67ivt8t1P3omRVzsj9NfxY2t41JLjmjT6X0vtBQHKQ@mail.gmail.com> <1fc7816e-6179-28d6-7b11-be2027561a54@si6networks.com> <CALx6S37KXfLE22uHMZTD41+jR7fdZd9PZGqO-r4SE2LehtN=Gg@mail.gmail.com> <2d312ecf-e037-5c24-28d7-2a2c3dc06363@si6networks.com>
In-Reply-To: <2d312ecf-e037-5c24-28d7-2a2c3dc06363@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 28 Jan 2020 16:17:04 -0800
Message-ID: <CALx6S37A1QzR0PhDUzujXGiB+a-9c1qG4g8TE8KOcxOLKP18TQ@mail.gmail.com>
Subject: Re: Address privacy
To: Fernando Gont <fgont@si6networks.com>
Cc: Nick Hilliard <nick@foobar.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qQzuRLPa4EuACmw2luNdZenf6mY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 00:17:19 -0000

On Tue, Jan 28, 2020 at 3:45 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> On 28/1/20 19:45, Tom Herbert wrote:
> [...]
> >> I don't think you can quantify privacy. What would be the units for that?
> >>
> >> There's secrecy and not-secrecy. But with these things, you simply
> >> mitigate (to some extent) the ability to correlate network activity.
> >>
> > Fernando,
> >
> > In the case of single use addresses, that is each flow gets its own
> > addresses, the privacy effects are quantifiable. Since each flow has a
> > different source address, no two flows or communications can be
> > correlated to being sourced from the same user. In this case, the
> > identifiers are not reused is used in multiple contexts, so it isn't
> > possible to correlate seemingly unrelated activity using an
> > identifier. When an identifier is reused for the same node, even once,
> > then the possibility of correlations exists.
>
> You are not quantifying privacy: that's still qualitative description.
>
It is quantified. If a flow uses a unique address then the risk of
using the address of packets in the flow to correlate to other flows
is zero.

>
>
>
> >>> One might compare this to the policy of some sys admins that users need
> >>> to change passwords regularly. The rationale is similar, but that
> >>> practice has been most debunked as not improving security and in fact is
> >>> more of a burden to users that providing any real value.
> >>
> >> I don't think it has been debunked. Certainly, if you change your
> >> password, you limit the ability of the attacker that had obtained your
> >> password from re-using the same credentials. (assuming they are not used
> >> for a system where they can install backdoors, etc.). Most things we
> >> emply for security have an associated lifetime...
> >>
> > It's a false sense of security. Here's a good analysis:
> > https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes
>
> Forcing password changes exacerbate some human aspects, and at times
> leads to trouble. That doesn't say it doesn't have a place.
>
> Folks also argue that firewalls are a false sense of security. Some
> argue the same about resistance to address-scan -- even when the #1 task
> to hack a system is normally to find it. IMO, whatever makes the
> attacker's life harder has a place and a use.

For things like address-scan and breaking a key, the risk of attack
can be quantified based on existing processing capabilities needed for
brute force attack. Deriving correlations between flows based on
addresses isn't quantifiable in the same way since it's not a brute
force attack.

Regardless, I still haven't seen a reasonable answer to user's obvious
question regarding temporary address: "What should my frequency of
address change be to ensure my privacy?"

Tom

>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>