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

From: David Schinazi <[email-masked]>
Date: Wed, 14 Nov 2018 17:37:00 -0800

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

---

From: Christopher Wood <[email-masked]>
Date: Wed, 14 Nov 2018 17:51:37 -0800

On Wed, Nov 14, 2018 at 5:37 PM David Schinazi <[email-masked]> wrote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about DNSSD privacy:
> 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.
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Christopher Wood <[email-masked]>
Date: Wed, 14 Nov 2018 17:55:10 -0800

(Oops. Actual text below.)

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

One issue Christian and I discussed after the meeting concluded is the
possibility of dictionary attacks on the service identifier. With the
predictable nonce obfuscation proposal, which would necessarily
include the service identifier in the first query, leaking the client
public key to an adversary allows offline dictionary attacks on the
service. Whether or not this is a problem depends on the threat model.

Note that it's likely possible to bootstrap the two-stage approach
using the single-stage approach. But that would bring back in the
question of whether or not to use TLS.

Best,
Chris

---

From: Christian Huitema <[email-masked]>
Date: Wed, 14 Nov 2018 18:34:51 -0800

> On Nov 14, 2018, at 5:55 PM, Christopher Wood <[email-masked]> wrote:
> 

I agree this id an attack, but it is a secondary exploit of leaking the key. My take is that leaking the key is a catastrophic failure, which enables tracking the key's owner movements. Leaking the service ID on top of the user identity is not good, but service connections can also be identified by various fingerprinting methods. If you are paranoid, use a two stage method. But in most cases, the trade off between risk and performance will favors the one stage approach.

> question of whether or not to use TLS.

I would personally rather use TLS than invent something, but Bob's draft is probably fine too.

-- Christian Huitema

---

From: Bob Bradley <[email-masked]>
Date: Wed, 14 Nov 2018 21:36:15 -0800

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 <[email-masked]> wrote:
> 
> Hello everyone,
> 
> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s <https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2018 10:23:17 -0500

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 <[email-masked]> 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).
>
> 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.
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 15 Nov 2018 08:30:31 -0800

> On Nov 15, 2018, at 7:23 AM, Ted Lemon <[email-masked]> 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?

I am concerned that we are debating hypothetical designs here, pieces of the original design with pieces of Bob's design. Everybody will have different ideas about the mix, and different worries. My goal is to work with Bob and Daniel and propose an actual design for evaluation.

Spoofing is indeed a concern, and so are replay attacks. The join design will have to address that.

-- Christian Huitema

---

From: Bob Bradley <[email-masked]>
Date: Thu, 15 Nov 2018 08:32:05 -0800

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 Thu, Nov 15, 2018 at 12:36 AM Bob Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Nov 14, 2018, at 5:37 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello everyone,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2018 11:37:52 -0500

Oh, right, if you share your public key with a printer, and it's the same
key you use with everyone else, then now in principle the printer can troll
for devices with which you've shared your key.

On Thu, Nov 15, 2018 at 11:32 AM Bob Bradley <[email-masked]> wrote:

> 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.
>
>> 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
>> 4. One privacy concern regarding predictable nonces is that it would
>> allow spoofing. Anyone with your public key could generate your predictable