Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01

[Christian Huitema <[e-mail]>]

On 6/25/2017 2:07 PM, Stephane Bortzmeyer wrote:
> On Mon, Jun 19, 2017 at 02:24:36PM +0000,
>  Tim Chown <[e-mail]> wrote 
>  a message of 38 lines which said:
>
>> We are initiating a WG Last Call today on
>> draft-ietf-dnssd-privacy-01, as can be found at
>> https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01
> Read it and it seems OK to me. But I see one technical weakness, and
> two things that I find puzzling.
Thanks for the review.

> In section 3.2.2, if I understand correctly the proposal for a
> predictable nonce, it seems to me it has a weakness: end-users
> machines do not always have proper clock synchronisation (see also 5.5
> which mentions it, for an unrelated issue). True, taking only the
> first 24 bits of the time will help (some machines with different
> clocks will nevertheless end in the same time interval), but it is not
> sufficient if bad luck makes two machines fall in different intervals.
True. The solution requires that the participating devices have "good
enough" clocks -- to the minute, in practice. It is clearly a trade off
between usability and performance, and also resistance to DOS. The
initial design had unconstrained nonce instead. The problem with
unconstrained nonce is that they cannot be pre-computed by the peer,
which open the possibility of a DOS attack: creates many nonces, and
force the peer to compute as many hashes. Besides, nonces have a
weakness too -- end-user machines do not always have proper sources of
randomness.

So in practice we require end users machines to have some sense of time.
Maybe we should be more upfront about that.

> In section 2.4 "There is however an argument that devices providing
> services can be discovered by observing the local traffic" Another
> weakness of this argument is not mentioned: mDNS is multicasted so
> anyone can listen, eve on a switched network. Local traffic isn't.
Good point. Will fix that text.
> In section 3.4, "Host names are typically not visible by the users,
> and randomizing host names will probably not cause much usability
> issues." Is it always true? It seems to me several discovery protocols
> (over Bluetooth for instance) display the host name to the end user.
In DNS-SD, host names are not meant to be visible. The UI examples all
use the instance name.

We did consider something like an aliasing system for host names. Once
devices have recognized each other, they could "decrypt" the host name,
so applications could use it directly.

Any suggestion?

-- Christian Huitema