Subject: Re: [dnssd] Next steps for privacy discovery

From: Mohit Sethi M <[email-masked]>
Date: Sat, 3 Nov 2018 03:43:24 +0000

Hi Christian,

I would recommend you to have a look at EAP-NOOB (https://tools.ietf.org/html/draft-aura-eap-noob-04). The draft is doing things at a different layer and is solving a different problem. It is doing pairing between a device and a virtual cloud service (EAP server).

However, many of things are related and could be useful for your work. As you rightly note in https://tools.ietf.org/html/draft-ietf-dnssd-pairing-info-02, OOB channels do not provide confidentiality. EAP-NOOB is designed in a way that  prevents impersonation and man-in-the-middle attacks even in situations where the attacker is able to eavesdrop the OOB channel. The "Authentication principle" section has more details: https://tools.ietf.org/html/draft-aura-eap-noob-04#section-6.1

--Mohit

On 10/30/18 12:20 AM, Christian Huitema wrote:

On 10/28/2018 6:48 PM, Lanlan Pan wrote:

Christian Huitema <[email-masked]<mailto:[email-masked]>>于2018年10月26日周五 下午3:09写道：
...

4) If we kept the current "two phase" structure, use a TLS protocol
extension to demonstrate knowledge of the server's public key in the
client hello. I think we can build on the work done for SNI encryption,
which would fit quite well.

I wonder if we could consider about use tls psk (pre-shared key) ?  server can assign different key to different client.

That's what we were specifying in the current privacy draft. There are two issues. The first one is that if you use TLS-PSK, the Client Hello must include a key identifier. If there is a different key for each client, the key identifier could become a client identifier. We solved that  by using a "predictable nonce" for key identifier. The second issue is of course that assigning different keys to different clients requires extra management at the server, something that is not needed in the "private public key" class of solutions.

-- Christian Huitema

_______________________________________________
dnssd mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnssd

---

From: Christian Huitema <[email-masked]>
Date: Sun, 4 Nov 2018 08:55:29 +0700

On 10/26/2018 11:57 PM, Bob Bradley wrote:
> If I understand correctly, a revision to draft-ietf-dnssd-privacy-05 would change it from each server advertising a _pds._tcp service instance for each of its paired peers to advertising a single _pds._tcp service instance for only itself (which sounds like a nice improvement). For that case, I think the scalability comparison between predictable nonces vs trial decryptions would be the cost of filtering additional multicast traffic vs performing additional signature verifications.
>
> Assuming a network with 50 peers and 3 of them I'm paired to, here's my understanding of the work between the two approaches:
>
> Predictable nonces:
>
> When I join the network and start discovery, I announce my own _pds._tcp service instance (hash of time). Each peer would receive it and for each of its paired peers, calculate PrivateInstanceName = <time> | hash( <time> | <peer public key> ) and compare that to the announced name (47 ignore it, 3 cache it). Then send a PTR query for _pds._tcp. Each peer on the network responds with its own _pds._tcp service instance. For each response I receive, calculate a PrivateInstanceName for each of my paired peers and compare each response to my list of PrivateInstanceNames (47 ignored, 3 cached).
>
> Trial decryptions:
>
> When I join the network and start discovery, I announce my availability via a probe (signature of time) . Each would peer would receive it and for each of its paired peers, perform a signature verification (47 ignore it and 3 cache it). The 3 paired peers send a response. When I receive each response, perform a signature verification against each of my paired peers (which should succeed so it caches all 3 responses).
>
> The question seems to be whether the traffic reduction in the trial decryption approach of only needing to respond to paired peers is worth the CPU cost of additional signature verifications.
>
> Another option could be to use the predictable nonce approach, but in the PTR query for _pds._tcp, include an additional record containing the predictable nonce of the querier. The receiver could use this to suppress responses to unpaired peers. This could provide a similar traffic reduction to the trial decryption approach while retaining the CPU optimization of predictable nonces.

I do like the reduction in number of queries caused by "trial
decryption". As you point out the CPU cost could be mitigated by adding
a predictable nonce to the client queries, with the "proof" part of the
nonce computed by hashing the client's public key.

The idea of sending queries signed by the client is indeed sound, as it
enables servers to only respond to authorized clients. But it requires
that servers process queries in real time, and that's not compatible
with the "server based" mode of DNSSD, in which application servers
prepare responses in advance and store them in records published by the
DNS servers. So the decision boils down to how much compatibility we
want to retain with the "server based" more of operation.

-- Christian Huitema

---

From: Daniel Kaiser <[email-masked]>
Date: Wed, 7 Nov 2018 16:57:36 +0100

Summarizing, the differences between our privacy draft and the new
privacy draft are:

(1)  keys derived from shared secrets    vs     keys derived from
asymmetric keys
(2)  hints (using predictable nonces)      vs     trial decryptions
(3)  backwards compatibility                  vs     defining new RRs

My question is: Why do we need another privacy draft?
The new draft also uses our two-stage approach, meaning first
discovering paired peers and then engaging in direct discovery with them.
Issue (1) already came up during past meetings; as soon as we have
consensus, we can go ahead and adapt our draft accordingly.
Regarding issue (2) nobody opposed when we suggested using hints instead
of trial decryptions for performance reasons. We could assess this issue
again.
I also like the idea Bob Bradley pointed out: sending a predictable
nonce in the client PTR query to allow for suppressing unnecessary messages.
This is similar to our direct query method, which also reduces the
number of sent messages (we should discuss this as well).
We should try to get consensus on (3) tomorrow; if defining new RRs is
the preferred way, we could merge that part into our draft.

Further, in past meetings there has been discussion as to whether we
should switch to a one-stage approach supporting a per-app model, or
stick with our two-stage approach.
We could also support both, which I would prefer, modeling the second
stage of the two-stage approach as a service of
a "DNS server app" that is discoverable via a privacy preserving
one-stage solution.

Also, I wanted to ask if the new draft is meant for DNS-SD/mDNS
exclusively or also for DNS-SD/DNS.
I think, the protocol should not be called Bonjour, because Bonjour is
the name of a concrete implementation of DNS-SD/mDNS.

Kind regards,
Daniel Kaiser

-- 

Dr. Daniel Kaiser
Research Associate
SnT- Interdisciplinary Centre for Security, Reliability and Trust

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010

On 11/04/2018 02:55 AM, Christian Huitema wrote:
> [email-masked]

---

From: Daniel Kaiser <[email-masked]>
Date: Wed, 7 Nov 2018 17:00:30 +0100

Regarding the trade-off between hinting using predictable nonces and
trial decryptions,
I wanted to add that we could also use a bloomfilter based solution for
reducing the
number of necessary hinting messages while not needing costly trial
decryptions.

I summarized the current state of my idea in the attached markdown document.
If you are interested, I could elaborate on this idea.

Kind regards,
Daniel Kaiser

-- 

Dr. Daniel Kaiser
Research Associate

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010