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

David Schinazi <dschinazi.ietf@gmail.com> Tue, 26 February 2019 17:35 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51412130ECD for <dnssd@ietfa.amsl.com>; Tue, 26 Feb 2019 09:35:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC5xLhMnhEUC for <dnssd@ietfa.amsl.com>; Tue, 26 Feb 2019 09:35:37 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C96130E5D for <dnssd@ietf.org>; Tue, 26 Feb 2019 09:35:36 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id p19so6576388plo.2 for <dnssd@ietf.org>; Tue, 26 Feb 2019 09:35:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dCJKC0jmUOyXSLmRVNrHcL3t1QGNyTK4w2bPz97gZkc=; b=ZLJWDzTY/V2NEQAZEWi0ufv+VosZcU9XL/814uZnmHIre3yuYZsUFrQ9+wG3/6bjLz FkKj0/i8wQ6VjGMSpL7/uxSIJ/nN6R56Mw+jQ9zy7ffm8cE9J2BdiFz0oZ2SAuuvsUM3 g4nyrGC/fYUh0JKuU9e+3NecTK6ajjixf5919F8MdPMBkkzbvlEeYmPCVlfO83C5hHtu i3lOqaSzDT4zE4KRdx3EVQK59S08wycPR70MGLJHY1/K+K2vyZRc8p7DOBBIBsszwoug 21ERsfQYyDOa5wnGz93lvPnnnbHDTW9mbrttucBw+mLj9EshFNlO0gNnJV4S6EaLEKeP 0/NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dCJKC0jmUOyXSLmRVNrHcL3t1QGNyTK4w2bPz97gZkc=; b=fR1CCpSarlF16mGjbUqqJLYquMe6HVPDOCT+vk3jIsPDKuWSLQ8F8I7cuhhJjkXf8O lbMM+0XpXRnpRa8vDiA5dxskp5BGn61VytMRFlI57CjBeMX4OCvgFGJuIab6ULb3tkgI +fKjzpCJhPxJbGdLLBw+cHI7lrm/4xpuV3TngdDG6msvupascDTUTV7JTCk/jnToju4C Robqv8HqKShTdKx51DFGpXROfGMbPgBg83bwtzWiqukI6kiQyttiA95EZ3YsAYbrJRpR dl//pndW+WSB+kjZsgkip90lWLlJgyqwjb9AJWu2qCI9l534EqzJ0GJgRWw5A7eU+Cuy YJYg==
X-Gm-Message-State: AHQUAuYdrue6de53n+ms0DzBx6eP9z4276kavrBCqbIQzjhhJiDrg2i2 Lp8t5yCaNZMT6BNtWzUA8Hr+nYJJo+WvKbGL9rc=
X-Google-Smtp-Source: AHgI3IbRxcNwB5yTNoFHDbBlM0r7O9lDyLm9XHi6JyquGC9oHxFSybrhaSgSCpIjWB5MSRtfhLvb2jWy3jEnUuHGWtI=
X-Received: by 2002:a17:902:7207:: with SMTP id ba7mr26589311plb.16.1551202536287; Tue, 26 Feb 2019 09:35:36 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <CAO8oSXkGAErtKQgMGGT+88PY4Y+wJ_6Rz493exaymZ_L8F4FNg@mail.gmail.com>
In-Reply-To: <CAO8oSXkGAErtKQgMGGT+88PY4Y+wJ_6Rz493exaymZ_L8F4FNg@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 26 Feb 2019 09:35:25 -0800
Message-ID: <CAPDSy+68V=rx8cAbVq6rKxNbb9yHisCCPURwHoLKsA179NooLw@mail.gmail.com>
To: Christopher Wood <christopherwood07@gmail.com>, Christian Huitema <huitema@huitema.net>, Bob Bradley <bradley@apple.com>
Cc: DNSSD <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002673110582cf7c1f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/6IQ3tNj0NnpacEsmGz9QxG2V3EQ>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 17:35:46 -0000

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 <
christopherwood07@gmail.com> wrote:

> (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
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>