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

[David Schinazi <[e-mail]>]

Thanks for writing this up Christian.

I went through the minutes of our last in-person meeting in Bangkok
<https://datatracker.ietf.org/meeting/103/materials/minutes-103-dnssd> and
while we did not
explicitly ask for consensus then, I got a feeling that the sense in the
room was:

1) Is the server mode important for the scenarios that we are thinking
about?
    - No one in the room came out strongly in favor of server mode
    - Server mode would add complexity

    My personal recommendation: we declare server mode out of scope for now.

2) Do we care about compatibility with the existing DNS-SD formats?
    - No one in the room came out strongly in favor of this
    - It was mentioned it would be nice to have but not critical
    - This would cause some security tradeoffs regarding hash size

    My personal recommendation: we declare compatibility with existing
formats out of scope for now.

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 had briefly discussed this at IETF 100 in Singapore following
Stuart's discussion of requirements:

https://tools.ietf.org/html/draft-cheshire-dnssd-privacy-considerations-01#section-3
    - I recall there was support in the room for having finer granularity
such as per-app

    My personal recommendation: we focus on per-app for now.

Based on the above, as chair, I'm proposing we move forward with a reduced
scope solution for now,
that is without server mode, using binary formats, and runs as an app
library.
To clarify, this wouldn't mean we won't try to build a follow-up solution
for those requirements later,
this is just meant as framing to help us make progress towards a concrete
proposal.

Please share your opinions on this potential approach.

Thanks,
David

On Wed, Feb 27, 2019 at 10:35 AM Christian Huitema <[e-mail]>
wrote:

> 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]> wrote:
>
>> (Paging back in discussions from the meeting...)
>>
>> On Wed, Nov 14, 2018 at 9:36 PM 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).
>>
>> 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]>
>> 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
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>
> _______________________________________________
> dnssd mailing [e-mail]://www.ietf.org/mailman/listinfo/dnssd
>
>