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

[Ted Lemon <[e-mail]>]

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]> 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]>
> 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]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>