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

On 09/10/2016 09:24, Michael Richardson wrote:
> 
> Christian Huitema <huitema@huitema.net> wrote:
>     >> 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.
> 
>     > You need some signal -- you cannot build trust out of zero knowledge and
>     > zero signal.
> 
> I agree; recall how many times semi-technicals have suggested that having source IP
> 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

> 
>     > 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.
> 
> Looking forward to a link to read it!
> 
>     > As for the question whether devices need privacy, clearly it depends. My gut
>     > 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.
> 
>     > 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.
> 
> 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.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
> 