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

[Daniel Kaiser <[e-mail]>]

Thank you very much for the review.

Regarding the host names, I described a solution for privacy-preserving
host name resolution via mDNS in my thesis.
Summarizing, it works as follows (assuming Alice wants to resolve Bob's
host name):

• Bob offers a PTR and a SRV resource record for his _pds service
instance, and an A
resource record associated with his randomized mDNS name, e.g.
“AB1234EF.local”.
• Upon receiving Bob’s PTR resource record, Alice processes the hint
contained in the
service instance name and learns that it is Bob’s service instance.
• Alice resolves this service instance retrieving the corresponding SRV
resource record.
She then resolves the randomized hostname, “AB1234EF.local”, obtaining
Bob’s A
resource record.
• The daemon on Alice’s device updates the local DNS cache, and creates
a CNAME
record, establishing “AB1234EF.local” as a canonical name for
“bob.privacy.local”.
• Applications on Alice’s device can now simply use something like
gethostbyname("bob.privacy.local")  for resolving Bob’s private host name.

This name (or just the "bob" part of it) could then also be displayed it
in a UI...
But as Christian Huitema said, the GUI typically only shows instance names,
which is not influenced by our solution.

Should we add such a way of pirvacy-preserving host name resolution to
the draft?
We are currently working on a 02 version.

kind regards
Daniel



On 06/26/2017 04:18 PM, Christian Huitema wrote:
>
> 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
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd