[LINK] IPv6 vs. Human Security [Was Re: smartphone privacy problems]
Richard Chirgwin
rchirgwin at ozemail.com.au
Mon Jan 31 14:59:19 AEDT 2011
Roger,
It's feasible to me that in the original design of IPv6, privacy may
have been completely overlooked.
However, that doesn't mean this oversight persists:
http://tools.ietf.org/html/draft-ietf-ipv6-privacy-addrs-v2-05
My point - being only a so-so reader of protocol specs! - is that I
suspect we need to know what's in the whole protocol suite, as
implemented (or proposed to be implemented), to make a judgment.
A question: does anyone know whether those implementing v6 support (eg
in routers, etc) in 2011 take into account the existence of privacy
extensions?
RC
On 31/01/11 2:34 PM, Roger Clarke wrote:
> Right now, considerable effort is required before a law enforcement
> agency (or a marketer) can associate all of the messages that a
> person sends and receives from various locations using their portable
> device.
>
> If the IPv6 default remains in place, that 'natural' protection is
> destroyed, because the identifier is extractable from the IP-address,
> and both are persistent.
>
> Among the many design requirements for IPv6 had to be retention of
> natural protections of this nature.
>
> As things have transpire, one of the following must be true:
> - that vital design requirement wasn't recognised; or
> - it was recognised but not delivered
>
> Either is a failure by the designers.
>
> Yes, I agree that it would be a defence for the designers to have
> published a clear statement for users about what they have to require
> from their service providers and/or do themselves, in order to
> achieve protection. And that statement would indeed valuably extend
> up through the layers to cover more than device-ids and IP-addresses.
>
> (Whether it would be *sufficient* defence, to justify the insecure
> design, I'm less sure).
>
> But can you point us to that clear statement from the designers of IPv6?
>
>
>> "They" have an almost infinitely wide palette of possibilities. A system
>> that does not apply the rule of law, that is corrupt or whatever, will
>> not bother about the accuracy of the charges needed to achieve such
>> aims. Trumped up is trumped up. And why is this an "undefendable"
>> charge?
> The charge is undefendable because obfuscation can be readily
> interpreted as any act that prevents the IPv6 IP-address from
> containing the ID allocated by the manufacturer to the device.
>
> A government can then claim to be complying with, working within, and
> indeed enforcing, the rule of law.
>
> Without this appalling piece of design, no such easy manoeuvre would
> be available.
>
> _________________________________________________________________________
>
> At 12:30 +1100 31/1/11, Karl Auer wrote:
>> Content-Type: multipart/signed; micalg="pgp-sha1";
>> protocol="application/pgp-signature";
>> boundary="=-rvXP8VvYy/tFCBlP9oGW"
>>
>> On Mon, 2011-01-31 at 11:29 +1100, Roger Clarke wrote:
>>> I'm saying that, as I understand the discussion:
>>> (1) an IPv6-connected device is, by default, recognisable nomatter
>>> where on the net it may connect
>> You keep saying "default". In a technical sense, SLAAC is the default.
>> In any practical sense it is not. You have to get over this hump.
>>
>>> (2) this is an intentional design feature
>>> (3) the default may be over-ridden by a service-provider
>>> [That was the new information that hadn't been in previous posts:
>>> "the mechanism most likely to be actually used for hosts operated
>>> by humans does NOT expose the MAC"]
>>> (4) the feature's insecurity to humans may be addressed by users, but
>>> this involves [insert long list in my previous email], i.e.
>>> awareness, expertise and action that is beyond most users' capability
>> If and only if SLAAC is actually used by the service provider or
>> employer. Or home CPE; I suppose that is a possibility, though because
>> of the need for DNS information, I'd be tipping on DHCP there too.
>>
>>> The people responsible for that aspect of the design are in breach of
>>> their professional Code, and culpable.
>> No more than the designers of knives are culpable when a knife is used
>> to attack someone. You are going to have to come up with an *argument*
>> here, Roger, not just a statement that it is so.
>>
>>> (Yes, there are additional measures that people at risk need to use,
>>> such as nymising proxies, ToR and message encryption. But they're at
>>> higher levels of the stack than IP. Raising awareness of them, and
>>> making their use sufficiently simple is very important. But it's
>>> out-of-scope of a discussion about Internet architecture as dictated
>>> by the design of IPv6).
>> Not at all. Any more than a discussion of safe storage, proper handling
>> practices and so on are inappropriate when discussing nice, sharp,
>> useful knives.
>>
>>> It's very useful to law enforcement agencies to have a simple and
>>> un-defendable charge that can be used first, thereby achieving the
>>> gaoling of the miscreant on-remand and without bail.
>> You go on to build an oak tree of catastrophe from an object that is not
>> even vaguely acorn-shaped.
>>
>> "They" have an almost infinitely wide palette of possibilities. A system
>> that does not apply the rule of law, that is corrupt or whatever, will
>> not bother about the accuracy of the charges needed to achieve such
>> aims. Trumped up is trumped up. And why is this an "undefendable"
>> charge?
>>
>> Seriously - while this is an aspect of IPv6 that *could* under certain
>> limited circumstances be used in citizen- or consumer-unfriendly ways,
>> it is a tiny, tiny drop in a sea of such difficulties, the vast majority
>> of which have nothing to do with a layer 3 protocol.
>>
>> Regards, K.
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h)
>> http://www.biplane.com.au/kauer/ +61-428-957160 (mob)
>>
>> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
>> Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
>>
>>
>> Content-Type: application/pgp-signature; name="signature.asc"
>> Content-Description: This is a digitally signed message part
>>
>> Attachment converted: Rincewind:signature 9.asc ( / ) (006A625C)
>> _______________________________________________
>> Link mailing list
>> Link at mailman.anu.edu.au
>> http://mailman.anu.edu.au/mailman/listinfo/link
More information about the Link
mailing list