[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