Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok

[Christian Huitema <[e-mail]>]

I think we understand the envelope of the solutions, but we have to
stabilize three design choices first:

1) Is the server mode important for the scenarios that we are thinking
about?

2) Do we care about compatibility with the existing DNS-SD formats?

3) Do we want private discovery to work as a system component, or as an
app library? (a.k.a. per device or per app.)

We can easily write a spec that works without server mode, using binary
formats, and runs as an app library. That's basically Bob's design, with
an optional tweak to add an hint and minimize the CPU cost of trial
decryption. We could also tweak the same spec and make it somehow fit in
DNS formats, with a liberal usage of TXT records, but I don't know
whether that's justified. We do not have a consensus on a server based
solution, let alone on a server based solution that would reuse DNS
servers. 

Basically, the best way for the chairs and the working group to help is
to focus the work on a key scenario, and answer the three questions above.

-- Christian Huitema


On 2/26/2019 9:35 AM, David Schinazi wrote:
> Thanks for kicking this discussion off again, Chris!
>
> Bob, Christian, is there anything the chairs can do to facilitate
> making progress towards a joint proposal before Prague?
>
> Thanks,
> David
>
> On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     (Paging back in discussions from the meeting...)
>
>     On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > I'm a little unclear what is being considered single-stage vs
>     two-stage. How is single-stage able to send encrypted without
>     knowing the destination? Is it encrypting a query with an
>     asymmetric private key and multicasting? Or does single-stage
>     refer to the predictable nonce approach? I was considering
>     predictable nonce's two-stage because it has to first discover
>     known peer service instances (stage 1) then perform encrypted
>     queries/responses (stage 2).
>
>     If I understand and remember correctly, the single stage approach
>     would encrypt the service ID in the first query using the recipient's
>     public key, along with the predictable nonce generated using the
>     sender's public key. The response would contain the address of the
>     service in question. If we are concerned with the dictionary attack
>     mentioned earlier, a second round is required.
>
>     I assume the joint design with you, Christian, and Daniel will attempt
>     to find an appropriate balance here.
>
>     Best,
>     Chris
>
>     > Regarding the discussion:
>     >
>     > 1. Server mode. My proposal doesn't have a good way to support
>     it. Normal server mode wasn't an important use case for me, but
>     sleep proxy support would be nice. I just don't know how to do it
>     yet, at least not without giving the sleep proxy your keys.
>     >
>     > 2. Multicast traffic. One problem I saw with
>     draft-ietf-dnssd-privacy is each device advertising a service
>     instance for each pairing. The network I'm on now has 300+ devices
>     and if each one has 50 friends, that's 15000 service instances on
>     the network, which seems very high.
>     >
>     > I tried to reduce this by each device only advertising itself
>     via multicast and then everything else is unicast. The first part
>     of key exchange was also rolled into the advertisement packet to
>     allow a single query packet and single response packet while still
>     maintaining forward secrecy and per-pairing confidentiality.
>     >
>     > 3. CPU cost. This seems to be a comparison between more packets,
>     but lower per-packet cost (in the per-pairing service instance
>     model where predictable nonce hashes are precomputed) vs fewer
>     packets, but more expensive per-packet signature verification. The
>     two main use cases I was considering were home networks (where
>     neither traffic nor CPU is likely to be an issue due to the small
>     number of devices) and busy enterprise networks (office, dorm,
>     coffee shop), which I assumed would be more powerful devices
>     (laptops, phones, servers) where reducing traffic would be more
>     important than the CPU usage for checking multicast probes.
>     >
>     > 4. One privacy concern regarding predictable nonces is that it
>     would allow spoofing. Anyone with your public key could generate
>     your predictable nonce. It could also enable friend relationships
>     to be recovered. Maybe not a huge concern, but something to
>     consider. Even the signature approach has a replay vulnerability,
>     but it's time bounded.
>     >
>     > On Nov 14, 2018, at 5:37 PM, David Schinazi
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     > Hello everyone,
>     >
>     > It the room at IETF 103, there was a very productive discussion
>     about DNSSD privacy:
>     > https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s
>     >
>     > During that discussion, the room reached consensus on the
>     following items:
>     >
>     > 1) single-stage approach -- Up until now, we were considering
>     two approaches: single-stage (send encrypted and authenticated
>     service identifier, receive encrypted and authenticated service
>     response) and two-stage (send encryption and authenticated
>     identifier, receive encrypted and authenticated response, derive
>     secrets, send and receive subsequent queries encrypted using
>     derived secrets). There was consensus in the room to go with the
>     single-stage approach.
>     >
>     > 2) Use of TLS -- The single-stage approach no longer requires a
>     key exchange mechanism such as TLS. There was consensus in the
>     room that we do not need TLS as part of this protocol.
>     >
>     > 3) Evolution of documents -- It was proposed that we would take
>     all input and compound it into a single document and only advance
>     that one. We will use draft-ietf-dnssd-privacy since that document
>     has already been adopted by the working group. Christian Huitema
>     has offered for Bob Bradley to join as co-author if Bob would like.
>     >
>     > If you disagree with any of these points, please say so before
>     2018-12-02.
>     >
>     > Thanks,
>     > David
>     > _______________________________________________
>     > dnssd mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/dnssd
>     >
>     >
>     > _______________________________________________
>     > dnssd mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/dnssd
>
>     _______________________________________________
>     dnssd mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd