Subject: [perpass] privacy implications of UUIDs for IoT devices

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 5 Oct 2016 17:54:46 -0600

Over on the CORE WG list, we've had a little discussion about the 
desirability (or not) of unique identifiers for devices in the Internet 
of Things. The message below provides some context.

I'd be curious to learn more about the attack surface lurking behind 
Stephen Farrell's comment that having long-term stable identifiers for 
IoT devices is a privacy-unfriendly practice because people will abuse 
such identifiers.

To be clear, the scenarios I have in mind are not specific to CoAP and 
don't always involve IP-based networking (the technology I'm working on 
these days enables mesh networking over long-range radio), but they do 
involve discovery and eventual communication that is both end-to-end 
encrypted and as close to metadata-hiding as possible.

Thanks!

Peter

-------- Forwarded Message --------
Subject: Re: [core] Implications of IP address / port changes for CoAP & Co
Date: Thu, 6 Oct 2016 00:11:26 +0100
From: Stephen Farrell
To: [email-masked] <[email-masked]>

Hi Peter,

On 06/10/16 00:03, Peter Saint-Andre - Filament wrote:
> On 10/5/16 4:28 PM, Stephen Farrell wrote:
>
>> On 05/10/16 23:22, Dave Thaler wrote:
>>> It is important that every device have a unique UUID that is
>>> endpoint-address-agnostic and protocol-agnostic.
>>
>> Considering the privacy implications I'm not at all sure I'd
>> accept that argument. In fact I'd argue we ought encourage
>> that devices not have globally unique long-term identifiers at
>> all unless there is a real need for those, and unless we
>> understand how to control their (ab)use.
>
> By "identifier" do we necessarily mean "network identifier"? It seems to
> me that it is useful to have a unique long-term identifier for every
> device, based on its public key. Whether you can obtain a network
> connection to that device based on such information is another story.

It is undoubtedly useful to have long term stable identifiers of
various kinds. I'd include key IDs and public keys as such.

Turns out that it's also fairly universally privacy unfriendly
as people will abuse such identifiers for good and bad reasons.

So I think we need to get much better at analysing when such
things are really needed and in what scope. My bet is that a lot
of the time a locally or probabilistically unique more transient
identifier would be just fine.

But yeah, I can't prove that. OTOH there is a hint in the term
"IMSI catcher" isn't there?

Cheers,
S.

> Peter

---

From: Dave Thaler <[email-masked]>
Date: Wed, 5 Oct 2016 23:59:10 +0000

https://tools.ietf.org/html/draft-thaler-core-redirect-00#section-1 is a short summary I wrote last month about this problem.

-----Original Message-----
From: Peter Saint-Andre - Filament [mailto:[email-masked]] 
Sent: Wednesday, October 5, 2016 4:55 PM
To: [email-masked]
Cc: Dave Thaler <[email-masked]>
Subject: privacy implications of UUIDs for IoT devices

Over on the CORE WG list, we've had a little discussion about the desirability (or not) of unique identifiers for devices in the Internet of Things. The message below provides some context.

I'd be curious to learn more about the attack surface lurking behind Stephen Farrell's comment that having long-term stable identifiers for IoT devices is a privacy-unfriendly practice because people will abuse such identifiers.

To be clear, the scenarios I have in mind are not specific to CoAP and don't always involve IP-based networking (the technology I'm working on these days enables mesh networking over long-range radio), but they do involve discovery and eventual communication that is both end-to-end encrypted and as close to metadata-hiding as possible.

Thanks!

Peter

-------- Forwarded Message --------
Subject: Re: [core] Implications of IP address / port changes for CoAP & Co
Date: Thu, 6 Oct 2016 00:11:26 +0100
From: Stephen Farrell
To: [email-masked] <[email-masked]>

Hi Peter,

On 06/10/16 00:03, Peter Saint-Andre - Filament wrote:
>> Considering the privacy implications I'm not at all sure I'd accept 
>> that argument. In fact I'd argue we ought encourage that devices not 
>> have globally unique long-term identifiers at all unless there is a 
>> real need for those, and unless we understand how to control their 
>> (ab)use.
>
> By "identifier" do we necessarily mean "network identifier"? It seems 
> to me that it is useful to have a unique long-term identifier for 
> every device, based on its public key. Whether you can obtain a 
> network connection to that device based on such information is another story.

It is undoubtedly useful to have long term stable identifiers of various kinds. I'd include key IDs and public keys as such.

Turns out that it's also fairly universally privacy unfriendly as people will abuse such identifiers for good and bad reasons.

So I think we need to get much better at analysing when such things are really needed and in what scope. My bet is that a lot of the time a locally or probabilistically unique more transient identifier would be just fine.

But yeah, I can't prove that. OTOH there is a hint in the term "IMSI catcher" isn't there?

Cheers,
S.

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Oct 2016 10:01:15 +1000

As an example the IEEE MAC registry is really only to provide
uniqueness, but its been demonstrated to act as a passive-capture
mechanism to identify probable host architecture from on-the-wire
sniffs. This then leads directly to: "If its a Dell, then I know the
iDrac default password so I can attempt to see if this is a badly
configured Dell which has iDrac IPMI on the host address" and like
attacks.

Unique identifiers are being used by the cellular provider to offer
price differentiated service to people on the same basic substrate.
Which is a poshed-up way of saying you can get a SIM which is dataplan
for an iPad but if you put it in your phone you are in breach of
contract over the use of that SIM. I am not personally a fan of this
legalism, but it is legal, and it is an ism.

I think there is a fundamental tension between baked in uniqueness,
probabalistic uniqueness (think ULA) and non-unique state in Layer-2
and Layer-3

-G

On Thu, Oct 6, 2016 at 9:54 AM, Peter Saint-Andre - Filament
<[email-masked]> wrote:
> desirability (or not) of unique identifiers for devices in the Internet of
> Things. The message below provides some context.
>
> I'd be curious to learn more about the attack surface lurking behind Stephen
> Farrell's comment that having long-term stable identifiers for IoT devices
> is a privacy-unfriendly practice because people will abuse such identifiers.
>
> To be clear, the scenarios I have in mind are not specific to CoAP and don't
> always involve IP-based networking (the technology I'm working on these days
> enables mesh networking over long-range radio), but they do involve
> discovery and eventual communication that is both end-to-end encrypted and
> as close to metadata-hiding as possible.
>
> Thanks!
>
> Peter
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Dave Thaler <[email-masked]>
Date: Thu, 6 Oct 2016 00:09:11 +0000

The issue with IEEE MAC's is that it's sent to untrusted observers, not that it is a stable identifier per se.
It just so happens that you typically don't have a choice but to send it in packets such that it can be observed
by untrusted observers, hence the need to use randomized MACs.

-----Original Message-----
From: George Michaelson [mailto:[email-masked]] 
Sent: Wednesday, October 5, 2016 5:01 PM
To: Peter Saint-Andre - Filament <[email-masked]>
Cc: [email-masked]; Dave Thaler <[email-masked]>
Subject: Re: [perpass] privacy implications of UUIDs for IoT devices

As an example the IEEE MAC registry is really only to provide uniqueness, but its been demonstrated to act as a passive-capture mechanism to identify probable host architecture from on-the-wire sniffs. This then leads directly to: "If its a Dell, then I know the iDrac default password so I can attempt to see if this is a badly configured Dell which has iDrac IPMI on the host address" and like attacks.

Unique identifiers are being used by the cellular provider to offer price differentiated service to people on the same basic substrate.
Which is a poshed-up way of saying you can get a SIM which is dataplan for an iPad but if you put it in your phone you are in breach of contract over the use of that SIM. I am not personally a fan of this legalism, but it is legal, and it is an ism.

I think there is a fundamental tension between baked in uniqueness, probabalistic uniqueness (think ULA) and non-unique state in Layer-2 and Layer-3

-G

On Thu, Oct 6, 2016 at 9:54 AM, Peter Saint-Andre - Filament <[email-masked]> wrote:
> desirability (or not) of unique identifiers for devices in the 
> Internet of Things. The message below provides some context.
>
> IoT devices is a privacy-unfriendly practice because people will abuse such identifiers.
>
> don't always involve IP-based networking (the technology I'm working 
> on these days enables mesh networking over long-range radio), but they 
> do involve discovery and eventual communication that is both 
> end-to-end encrypted and as close to metadata-hiding as possible.
>
> Thanks!
>
> Peter
>
> Turns out that it's also fairly universally privacy unfriendly as 
> people will abuse such identifiers for good and bad reasons.
>
> So I think we need to get much better at analysing when such things 
> are really needed and in what scope. My bet is that a lot of the time 
> a locally or probabilistically unique more transient identifier would 
> be just fine.
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Oct 2016 10:25:10 +1000

....And UUID generation on many devices includes a function over the
MAC address, as a cheap entry to guaranteed unique bits. Such that the
MAC may be randomized on the wire, but the UUID function exposed to
the device may well be repurposing the baked in ID in ways which
expose.

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Oct 2016 10:29:57 +1000

btw, my primary goal was illustrative not specific. persistent ID
threats are not exactly like MAC threats, but they probably lie in a
similar space. I have no major concern with the desire to be
deterministically both unique and known, I have this concern that the
mechanisms a manufacturer can use there, tend to processes (IEEE
Registry) which construct higher state (vendor-specific blocks) which
have side effects.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Oct 2016 13:34:25 +1300

I think people need to go and read draft-ietf-netconf-zerotouch
and draft-ietf-anima-bootstrapping-keyinfra. Then explain how we
could ever bootstrap a trustworthy network without some sort of
unique bitstring per device (in practice, an 802.1AR-2009 X.509
initial device identifier installed by the manfacturer).

That doesn't mean it needs to be visible in clear after bootstrap.

Regards
   Brian

On 06/10/2016 12:54, Peter Saint-Andre - Filament wrote:
> .

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 5 Oct 2016 18:05:02 -0700

On Wednesday, October 5, 2016 5:34 PM, Brian E Carpenter wrote:

> and draft-ietf-anima-bootstrapping-keyinfra. 

Another useful draft is draft-winfaa-intarea-broadcast-consider. It was
precisely motivated by the use of unique identifiers in device specific
broadcast protocols. UUID kind of fall in that category.

> Then explain how we

It also does not mean that the identifiers should be sent in clear text...

-- Christian Huitema

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2016 02:43:45 -0000

>by untrusted observers, hence the need to use randomized MACs.

It's not just that, it's that MACs have a structure and there's a
registry of prefixes so you can look at a MAC and know who the
manufacturer is and usually what kind of device it is.  For example,
prefix 2C-BE-08 is Apple, and anything with that prefix is probably a
Macbook.

If the unique ID is a version 4 UUID with no structure, I'd think
those particular problems would go away.  There may well still be
stuff you can derive from knowing that this device now is the same
as that device then.

R's,
John

---

From: Robin Wilton <[email-masked]>
Date: Thu, 6 Oct 2016 04:59:46 +0000

> stuff you can derive from knowing that this device now is the same

+1 ; any time you have a unique/linkable identifier that is sent without the user's knowledge/involvement, it undermines users' agency and therefore the trustworthiness of the system as a whole.

Yrs.,
Robin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Oct 2016 12:15:20 +0100

Hiya,

So I think this is a recurring theme in various protocols
and note that the drafts referenced in this thread overnight
[1,2,3,4] total 134 pages of text. So istm that there is
scope for a bit of generic guidance on the specific issues
about which Peter is asking, i.e. guidance on what kinds
of analysis to do when inventing or re-using an identifier
in a protocol, and (mainly via reference I'd hope) describing
the attack surface created when someone doesn't do that as
well as they might.

If someone was willing to try craft a short I-D addressing
the above, that'd I think be a fine thing. Anyone want to
volunteer to try that? (If so, replying on or off list is
fine.) Or is that a silly idea? (If you think so, then
replying on the list is way better:-)

Cheers,
S.

PS: If we had such an I-D we could figure out whether it'd
be better informational, or incorporated into 3552bis or
as it's own BCP, but it's premature to wonder about that
until someone writes text I reckon.

[1] https://tools.ietf.org/html/draft-thaler-core-redirect
[2] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch
[3] https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra
[4] https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Oct 2016 09:51:50 -0400

Dave Thaler <[email-masked]> wrote:
    > https://tools.ietf.org/html/draft-thaler-core-redirect-00#section-1 is
    > a short summary I wrote last month about this problem.

okay, so it just lets one repeat the query over COAPS.

With (D)TLS <=1.2, the server still reveals it's certificate identity in the
ServerHello to passive observers, and while (D)TLS 1.3 "solves" this for
passive observers, it doesn't help with active MITM.

Or the attacker can now just initiate DTLS1.3 (but doesn't have to finish it)
to find out the identity of the responding server.

It seems to me that the real problem is that attackers/observers are not
forced to reveal their identity first, in order that respondants can ask,
"Who wants to know?" first, and also better repell DDoS. (Attackers would
have to have validatable identities to even ask)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Oct 2016 09:54:09 -0400

> That doesn't mean it needs to be visible in clear after bootstrap.

I'm just keeping this here to emphasis the point.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Oct 2016 09:57:45 -0400

> It also does not mean that the identifiers should be sent in clear

I'd love to find a way to send the identifier only to an authorized operator,
which is resistant to an active MITM, given that the new device (the pledge)
doesn't know who the authorized operator is yet.

Encrypting it via a not-yet-fully authenticated TLS1.3 connection is easy.

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 6 Oct 2016 14:02:48 +0000

Hi,

(I was trying to not reply to this topic, but have failed.)

I am very happy to see this community addressing this topic.
I think it is really difficult; the implications for different actors
with differing motives illuminate the challenge.

1. I want to be able to control my devices to be able to report
  identifiers according to my desires.

2. As a network operator, I want to be able to limit access based
  on a fixed identifier that the user cannot change.

1. && 2. == False.

:-(

I gladly acknowledge that I am not an expert in this domain.

Can we find a space that allows human freedom and supports
the orderly operation of networks?  What are the compromises
involved in this?  Can we document them and describe the different
challenges for differing services?

/Hugo

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Oct 2016 10:09:06 -0400

> the attack surface created when someone doesn't do that as

The anima-bootstrap team spent three calls on this topic this past month.
I think that we may have a "HHGH" problem though (the answer being 42)
  i.e: the question here is not sufficiently specific.

    > replying on the list is way better:-)

I will volunteer, and I'll do this publically so that you'll hold me to it.
Expect it by draft cut-off date.

I think that I can summarize the situation for bootstrap well.
I don't know if it applies to operation or not, because I don't know what the
situation is for uses.

I think that there are significant operational differences between a BTLE
based *PERSONAL* area network (watch, heart monitor, phone) vs an unencrypted
WIFI at CoffeeShopInc.   The differences are very large, and I find that many
privacy discussions focus on the coffee shop to the exclusion of everything
else.

I also want to point out that MAC randomnization is probably far more
important than anything else because AFAIK, none of the 802.11 or 802.15.4
specifications offer to encrypt the L2 addresses, just the payloads.
(I think, but I'm unsure, that the BTLE L2 does encrypt the L2 addresses)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Oct 2016 16:54:32 +0100

> Expect it by draft cut-off date.

Excellent, thanks!

S.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 6 Oct 2016 18:41:19 -0700

On Thursday, October 6, 2016 6:58 AM, Michael Richardson wrote:
> ...

We are looking at that in the pairing draft in DNSSD
(https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The hypothesis
is that the two paired devices can display a short authentication string,
e.g. 6-7 digits. Given that, we can establish a TLS connection without prior
credentials between the two parties, with a probability 99.9999% that any
MITM attempt will be detected. But the two parties have to be able to "see"
the string display on the other device and compare it to the local one. ZRTP
uses the same algorithm to detect MITM in audio connection, probably
assuming that the parties will read the string over the audio channel and
that the MITM cannot really rework the audio in real time.

There is another trick, used in the privacy extensions to DNS-SD
(https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TLS PSK,
or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can only
be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK). That
guarantees connection without MITM, and also without disclosure of the
identities to third parties. Problem, it scales as O(number of PSK) known by
the server. We could probably devse an extension of that using public key
technology.

-- Christian Huitema

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 7 Oct 2016 09:48:37 -0400

The Eddystone ephemeral identifier for BLE work from Google may be of
interest to some here (doesn't solve cases of unknown neighbors):
https://developers.google.com/beacons/eddystone-eid

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

Tech Prom, CDT's Annual Dinner, is April 20, 2017!
https://cdt.org/annual-dinner

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Oct 2016 11:10:35 -0400

> is that the two paired devices can display a short authentication

This might be fine for larger devices with displays, but it's a fail
everywhere else.  Even in ANIMA, one could have a $300K BFR being deployed,
but it doesn't have a display or a person to read the display.
But, does this device need privacy?
But, the same system ideally bootstraps home routers, which at $39.95, still
don't have a display or a competent human to read the display.

    > credentials between the two parties, with a probability 99.9999% that

Such as was done with the STU-III phone...

    > the server. We could probably devse an extension of that using public key

How does the responding end know which PSK to try?
I guess that's why it scales O(number of devices), because the responder has
to try *all* of the PSK it knows?  Wow.

With public key technology, one could sign something, send the signature, and
let the responder try all the public keys it knows?  Basically, just omit the
Certificate in the handshake.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Oct 2016 11:11:26 -0400

> https://developers.google.com/beacons/eddystone-eid

It's a good solution for an ID once the system has been bootstrapped.

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Oct 2016 10:22:49 -0700

> don't have a display or a competent human to read the display.

You need some signal -- you cannot build trust out of zero knowledge and
zero signal. 

This is not a new problem -- I am copying Daniel, who studied all that in
great detail for his PhD. Over time, we have seen two solutions emerge for
device pairing. Visual comparison of "short authentication strings" is
arguably the best compromise between security and usability. It is widely
used when the devices can display something, e.g. when pairing smart phones,
tablets, PC and cars. The next most used solution is "push buttons". Push
buttons at the same time on both devices, and accept the messages exchanged
during that short time interval. If there is no MITM at that time, you are
good, but you have no way to know that. 

Many other solutions have been tried. One of them is to burn some kind of
key or code in one of the devices, document it on a tag, and use it on the
other device to verify the exchange. It may work for big expensive devices,
but it is a real pain for inexpensive devices because it introduces
additional steps in the manufacturing process. Besides, it requires that the
user reads and enters a long code, and that fails most usability tests.

Besides that, there are solutions that attempt to use alternative channels.
People have demonstrated pairing with the help of ultrasound, but that never
caught. The "synchronized blinking lights" are probably the cutest solution
from the literature. It is basically the same as short authentication
strings, but with no display, just one LED on each device. Instead of
displaying a hash on a screen, you use the hash to determine the pseudo
random blinking pattern of the two lights. If they blink in unison, the user
is assured that there was no MITM. Really cute, but has not quite caught on
yet.

As for the question whether devices need privacy, clearly it depends. My gut
feeling is that mobile devices do. Portable devices, most certainly do.

> to try *all* of the PSK it knows?  Wow.

BT-LE uses the same pattern. It works, as long as the number of PSK is not
too large. In our draft, we proposed a trick to reduce the server load. Use
a coarse clock as the nonce, e.g. the current time rounded to the nearest 10
minutes. This ensures that the server only has to compute the possible
hash(nonce, PSK) once every 10 minutes. It also defeats the potential DOS
attack in which a botnet bombs the server with connection requests and
forces lots of computations. But clearly there a limits. Would probably be
OK for a few hundred PSK, maybe a few thousands, but after that it breaks. 

> Certificate in the handshake.

It is actually very hard to protect the servers using public key technology
alone. The public key is not expected to be secret. If the attackers know
the public key, they can probe for the presence of a server by attempting a
connection. 

What might work is a combination of public key and PSK. Use the known public
key of the server to encode the PSK ID, and then add a proof that the client
sending the message owns the PSK. Third parties cannot deduce the client ID
or the server ID from the initial message, only the server can decrypt its
own public key and identify the client, and everything after that initial
message will be encrypted. You do have to include a nonce in the initial
message to prevent replay attacks, but it could work.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 Oct 2016 16:24:48 -0400

> You need some signal -- you cannot build trust out of zero knowledge and

I agree; recall how many times semi-technicals have suggested that having source IP
addresses was a privacy mistake, and we should remove them....

    > device pairing.

Looking forward to a link to read it!

    > feeling is that mobile devices do. Portable devices, most certainly do.

I think you are right, but there is a finer distinction to be made:
1) devices with no local identities that may need to be bootstrap'ed.

2) devices with local identities which are trying to join/use a new network.
   (the first time you visit CoffeeShop at corner of Fifth and Broadway)

3) devices with local identities which are re-joining a network they have
   been on before; but may not wish to leave a trace to a) the network
   operator,  b) other observers.

    > message to prevent replay attacks, but it could work.

In the bootstrap or CoffeeShop situation, is the Server part of the network?
In that case, how can the client know the public key of the network?

How is this not vulnerable to an active MITM using a different "known public key"?
This doesn't happen today with Wifi because a human either picks "CoffeeShop"
ESSID, or can validate the cert chain to say "CoffeeShop Inc", but a device
can't do this.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Oct 2016 00:14:59 +1300

> addresses was a privacy mistake, and we should remove them....

However, encrypting the source address as part of the payload would work. This
topic was in fact explored a few years ago:

J. Crowcroft. SNA: Sourceless Network Architecture.
In Perspectives Workshop: End-to-End Protocols for
the Future Internet, Schloss Dagstuhl, 2008.
www.cl.cam.ac.uk/~jac22/out/sna.pdf

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Oct 2016 01:12:43 -0300

> "IMSI catcher" isn't there?

At the risk of sounding our own horn, draft-gont-numeric-ids-generation
might be useful for guidance.

For instance, our I-D essentially argues that you should be asking
yourself the question: "what are the interoperability properties you
need for such IDs?".

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Oct 2016 01:20:13 -0300

> probabalistic uniqueness (think ULA) and non-unique state in Layer-2

Please see: draft-gont-numeric-ids-generation-01

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Oct 2016 01:28:35 -0300

> replying on the list is way better:-)

That's what we've tried to do in: draft-gont-numeric-ids-generation-01

Input welcome!

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Oct 2016 01:23:28 -0300

> by untrusted observers, hence the need to use randomized MACs.

The issue with MAC addresses is that they are constant across networks
when, if anything, they just need to be stable within the same subnet.

Besides, they have semantics (vendor ID) when in fact they need not.

And well, the problem is exacerbated by IPv6 SLAAC traditionally
generating IPv6 IIDs by embedding the underlying MAC address into them...

Thanks,

---

From: Eitan Adler <[email-masked]>
Date: Fri, 14 Oct 2016 04:14:56 -0700

> generating IPv6 IIDs by embedding the underlying MAC address into them...

Though RFC 4941 exists for this particular issue.

-- 
Eitan Adler

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2016 10:55:13 -0400

> Besides, they have semantics (vendor ID) when in fact they need not.

While I understand the concern, this is also a *feature* that is widely 
used.

When looking at devices seen on WiFi the vendor ID is often displayed 
and used to figure out which device is which, to correlate problem 
symptoms with likely causes, and many other reasons.

If this "feature" were to disappear there would likely be need to invent 
and *overt* feature to replace it.

	Thanks,
	Paul

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Oct 2016 16:07:03 +0100

> symptoms with likely causes, and many other reasons.

How often? Compared to how often those are uselessly sent?
(With the privacy downsides applying in all cases.)

I'm not saying that the "I need to debug stuff" arguments
for access to information are baseless, but I do think we
(techies) to better consider the privacy implications of
things like that.

S.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 14 Oct 2016 08:18:58 -0700

The MAC address issue is situational. When a device is moving, you want it not tracked, and you want the MAC random. At home, you don't care about the device privacy, and you want an easy way to do an inventory of what is on the network.

-- Christian Huitema 

> On Oct 14, 2016, at 8:07 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Ross Schulman <[email-masked]>
Date: Fri, 14 Oct 2016 11:28:42 -0400

In fairness, the vast majority of people have no such need "at home". I
would wager that 99.9% of people who use networked devices on a daily
basis have no idea what a MAC address is, would be at least somewhat
concerned that that sort of consistent data was leaking from them
constantly, and have no need to take an inventory of devices on a
network, nor any idea how they would do that even if they wanted to.

That "feature" is one that only a small portion of people (consisting of
many people on this list, granted) find important and IMO is outweighed
by the privacy and security implications.

-Ross Schulman

On Fri, Oct 14, 2016, at 11:18 AM, Christian Huitema wrote:
> The MAC address issue is situational. When a device is moving, you want
> it not tracked, and you want the MAC random. At home, you don't care
> about the device privacy, and you want an easy way to do an inventory of
> what is on the network.
> 
> -- Christian Huitema 
>

---

From: Robin Wilton <[email-masked]>
Date: Fri, 14 Oct 2016 16:28:13 +0000

+1, plus a small further comment: Paul says "if this feature didn't exist, we'd have to invent an overt equivalent" as if that's a bad thing.

>From my perspective, that kind of design decision ought always to be an overt one - especially where, as Stephen implies, an occasional use-case (trouble-shooting) is used as the justification for a permanent default with privacy implications (linkable, semantically-loaded MAC address).

I recommend Michelle Dennedy's book, The Privacy Engineer's Manifesto, and Sarah Spiekermann's book on Value-based Design, for useful and informative guidance in this area.

Hope this is of use,
Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2016 12:48:49 -0400

>>From my perspective, that kind of design decision ought always to be an overt one - especially where, as Stephen implies, an occasional use-case (trouble-shooting) is used as the justification for…

I'm ok with that. There may be a period when stuff people need to do 
gets harder because the new ways of doing it with privacy haven't yet 
been invented.

	Thanks,
	Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Oct 2016 11:18:40 +1300

> Though RFC 4941 exists for this particular issue.

And RFC 7217 for enterprise-like situations, RFC 7721 for general discussion
of the topic, and draft-ietf-6man-default-iids which is currently with the IESG.

    Brian