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

[Bob Bradley <[e-mail]>]

I wasn't as concerned with public keys leaking. The case I was thinking of is people I've shared my key with being able to determine who else I've shared with. If they haven't mutually shared keys, they can only determine if someone you've shared with is present. For mutually shared keys, they can identify specific people you've shared with: "Wow, I didn't know Alice and I both shared with Eve". For location-based devices, such as a printer or coffee shop, it can reveal where you've been.

> On Nov 15, 2018, at 7:23 AM, Ted Lemon <[e-mail]> wrote:
> 
> Hm.  To your point #4, I guess the question is, how easy is it for the public key to leak?   If you ever share your public key with anyone, they can definitely spoof you, but what do they get out of that?
> 
> On Thu, Nov 15, 2018 at 12:36 AM 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).
> 
> 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 <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 <https://www.ietf.org/mailman/listinfo/dnssd>
> 
> _______________________________________________
> dnssd mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>