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

["Christian Huitema" <[e-mail]>]

On Thursday, October 6, 2016 6:58 AM, Michael Richardson wrote:
>
> ...
> 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.

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