Re: [dnssd] Next steps for privacy discovery

[Bob Bradley <[e-mail]>]

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.

> On Oct 26, 2018, at 12:08 AM, Christian Huitema <[e-mail]> wrote:
> 
> With some prodding from David and Barbara, I resubmitted the DNSSD
> Privacy and Pairing drafts before the Bangkok meeting. The changes are:
> 
> * For both drafts, add reference to the privacy requirement draft and to
> the scaling draft,
> 
> * For both drafts, add a short paragraph in the intro stating that
> things might change based on the scaling analysis,
> 
> * For the privacy draft, remove the requirement analysis part and
> replace it by a reference to the requirement draft.
> 
> David is prodding me to write a complete revision of the privacy draft,
> using the "shared public key" approach, which has very good scaling
> capabilities and reasonably robust resilience to attacks. It is a bit
> different from the draft that Bob Bradley sent, and I will comment on that
> later. I could not submitted a revised discovery proposal before the dead
> line, but here are the broad lines of what I would do: 
> 
> 1) Server has a public key, which is "somewhat secret" -- it is only
> provided to authorized clients and they are expected to keep it secret.
> 
> 2) Single announcement per server of the form nonce|proof, where the
> nonce is a "predictable nonce" computed as a hash of quantized time and
> secret public key.
> 
> 3) Clients do a search for the nonce, just like in the current spec, but
> there is only one nonce per server, so the client will get exactly one
> response.
> 
> 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.
> 
> 5) We may consider having a different nonce for each available service,
> e.g. have the announcement computed as hash of quantized time, service
> type and secret public key. This would allow for a single phase solution.
> 
> 6) We may also have the service name used as a proof, e.g. encoding of
> nonce and service name with the server's private key.
> 
> 7) We need to say something about protecting the service connections
> from clients to server. DNSSD privacy would not be that much useful if
> the clear text data on the service connection revealed the identity of
> client or server. I think a combination of SNI encryption and TLS 1.3
> would work, but that may be extra work.
> 
> 8) We also need to recommend randomized host names for the A/AAAA
> records of the servers, otherwise there is also a big leak.
> 
> Some of the complexity in the DNSSD approach comes from a desire to fit
> into the existing DNSSD formats. This leads to some tricks like Base64
> encoding of nonce, time stamps and proofs so they fit in existing
> fields like service type or instance name. Bob's draft jettisons DNSSD
> compatibility and defines a new binary format. That is definitely
> cleaner, but there is a trade-off: a new protocol implies that we cannot
> reuse the DNSSD server infrastructure. It would be interesting to gauge
> the WG consensus on that tradeoff.
> 
> The other big difference between Bob's draft and the evolving proposal
> is the use of trial decryption. In Bob's approach, clients send probes
> that the server tries to decrypt by using the public keys of various
> registered peers or friends. This has scaling issues similar to the
> pairwise keys that we relied on in our first drafts. After discussions,
> we grew very concerned with these scaling issues and the
> corresponding potential for DOS attacks. We instead evolved towards
> a system of "predictable nonces".
> 
> The predictable nonces are a tradeoff between privacy and performance.
> Predictable nonces can be precomputed by the server, which reduces the
> processing cost and also limits the potential of DOS attacks. But then,
> all authorized clients of a server can generate the same predictable
> nonces, and thus all authorized clients can detect the presence
> of other authorized clients. This reduces privacy somewhat, although not
> necessarily by a whole lot. All authorized clients can discover the server,
> and thus retrieve its IP address. Network level analysis can then reveal
> which clients are also connecting to that server. This means that the information
> potentially leaked by the predictable nonce is also available at a lower
> layer. I think that the trade-off is thus between a minor privacy leak and
> a significant performance gain, but of course other WG members may have a
> different analysis. It would be interesting to gauge WG consensus on that
> subject.
> 
> Looking forward to the debates in Bangkok!
> 
> -- Christian Huitema
>  
> 
> 
> 
> 
> 
> 
> -- Christian Huitema
> 
> 
> 
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd