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

(Paging back in discussions from the meeting...)

On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <bradley@apple.com> 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 <dschinazi.ietf@gmail.com> 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
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd