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 >
- [dnssd] Confirming consensus from DNSSD Privacy d… David Schinazi
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Bob Bradley
- Re: [dnssd] Confirming consensus from DNSSD Priva… Ted Lemon
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Bob Bradley
- Re: [dnssd] Confirming consensus from DNSSD Priva… Ted Lemon
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… David Schinazi
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… David Schinazi
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… David Schinazi
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Bob Bradley
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christopher Wood
- Re: [dnssd] Confirming consensus from DNSSD Priva… Michael Richardson
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Martin Thomson
- Re: [dnssd] Confirming consensus from DNSSD Priva… Christian Huitema
- Re: [dnssd] Confirming consensus from DNSSD Priva… Daniel KAISER