Re: [dnssd] Next steps for privacy discovery

[Lanlan Pan <[e-mail]>]

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

> 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.
>

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


> 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
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan