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

Christopher Wood <christopherwood07@gmail.com> Thu, 28 February 2019 00:32 UTC

Return-Path: <christopherwood07@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 426D11311F0 for <dnssd@ietfa.amsl.com>; Wed, 27 Feb 2019 16:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Oe0M4LcGFoEz for <dnssd@ietfa.amsl.com>; Wed, 27 Feb 2019 16:32:01 -0800 (PST)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 F1AC4130EEC for <dnssd@ietf.org>; Wed, 27 Feb 2019 16:32:00 -0800 (PST)
Received: by mail-yw1-xc29.google.com with SMTP id r188so9565105ywb.12 for <dnssd@ietf.org>; Wed, 27 Feb 2019 16:32:00 -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=6elnUZP3REAXYYbRvtRKUTzVERnQrP5F7QeU4f321Hg=; b=kzBD7XvRFsN2Zt4LE8oSVebEcDtNBtdo+eFFbVWbKtsj3EgpatnwSIBQpFpQ7SEZjZ EBeyappl7JgGAr2wRIhFQnnlNjxDbWP91pKkRZC0KXpz43Y0dJmRMDUFWhhMzXgUBg+u ESbVn1cqOfV87gtDx7OtgSZMmiXvM8P/vEIRAeDLjz5oB5bylhAHAr3bpj6dN0mjBgfV 32ALtNIIZurqTD9kTLgfqwiqwEm1v8MJBFh3f6IqX8xiMo8oSkbE5eJmyWXHLCGP7/8c AxQwoBtK2oIWs8VshE2D8qq/BO1pf9yvMOfISC9ng5A180j2RVnfQWXdvu0om46UNw5e F43w==
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=6elnUZP3REAXYYbRvtRKUTzVERnQrP5F7QeU4f321Hg=; b=IYZZ2U9M8fxkaGtFIvoaC/HNm2qdV28W1OwsAQlJxp55V3ZDez4OcoZvRmgZdOMVg+ 2LLnQEkcG7G86aXTtYsfWhMjRH5pI7pOXuH6nH4SvMoNNYlvr4206o5eO1KgZzyXGCtX sD4EQPsaP48kb7XybkKhRKonxxA4zej36Fid4qKS5T7fQX6uVcJGSGxS8ZwNxD+6wYrX NZ2NnePTlmtI0/9MVpStbhyAxw3GkrK8EdASlHDXZqf+EWWs6xg1Eh7yXaMYcPMku3D5 4vMnCZfFBfxMGzwKFYbmDtIuzdAhK7JN4LumZnxkDPrHZDzafCHI+O5Kr/HVZbIsHqkZ FsmQ==
X-Gm-Message-State: AHQUAua1oPZWpJRpTLeGQIlZshKTe8Rwm45G4rP97EzGdC5ujQ57b97d C8m6ga0n5Un0gWRWv3aFJ6NEKQGoneq0EE8+RMQ=
X-Google-Smtp-Source: AHgI3IY23mBKsj0kBkrs37mZZ+n1JFMJQ9vQ2sr3EvVBMFKMqWybB+xfpTYC6VYFJeqNKXwpwyrTWX5oZGNNea63elc=
X-Received: by 2002:a81:2544:: with SMTP id l65mr3532988ywl.263.1551313919303; Wed, 27 Feb 2019 16:31:59 -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> <CAPDSy+68V=rx8cAbVq6rKxNbb9yHisCCPURwHoLKsA179NooLw@mail.gmail.com> <e9b4900d-94e3-c79a-2a72-e2f996663b9d@huitema.net> <CAPDSy+4d27SQCStGzPpzzv=pjGiCM+0df988BesRGHdV_vvteA@mail.gmail.com> <CAO8oSXnXre29hjbNCZ1N7b8VBRMubS1yO5_XXr7VY2yxzNAWGw@mail.gmail.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net>
In-Reply-To: <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net>
From: Christopher Wood <christopherwood07@gmail.com>
Date: Wed, 27 Feb 2019 16:31:48 -0800
Message-ID: <CAO8oSX=rWYxkKq0H5dEJDKq_Hs3tH2gqSxQ-Cr_SaHDPkrvvCA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, DNSSD <dnssd@ietf.org>, Bob Bradley <bradley@apple.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/rpboW9Mc_mKm5GRaY-fykXk8Qu4>
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: Thu, 28 Feb 2019 00:32:03 -0000

On Wed, Feb 27, 2019 at 2:17 PM Christian Huitema <huitema@huitema.net> wrote:
>
> OK. My next question is then how much commonality we want to have with TLS.
>
> All solutions in this space involve sending a broadcast query that asks
> whether some peer is present. The query is secured using some secret
> only known to the peers. From the previous discussions, we sort of
> agreed that this secret should be a "discovery public key", with the
> special twist that this public key should in fact be kept secret. The
> exchange would typically be an ECDH exchange, something like that:
>
> * Client broadcast a query, containing its own ECDH half key, a nonce, a
> proof, and possibly a hint.
>
> * The proof is secured by a "discovery secret", obtained by combining
> the ECDH half key and the server's discovery key. The optional hint is a
> cryptographic hash of the coarse time and the discovery secret
>
> * All servers get the message. If the hint is present they can verify
> that the query targets them. If no hint is expected, or if the hint
> matches, they compute the discovery secret and verify the nonce. If it
> is not verified, they just drop the message.
>
> * The responding server confirms the connection, sends its own ECDH half
> key, derives a handshake secret, etc.
>
> I notice that this is extremely similar to the TLS handshake, and
> especially to the QUIC or DTLS handshakes when using ESNI encryption.
> One simple way to deliver the functionality would be, just define a TLS
> extension for the "discovery proof". And with that, we would have a
> secure and private way to establish a DTLS session or a QUIC connection.

I think this highlights an important difference between the two
proposals on the table. Namely, whether or not service discovery
happens in one or two RTTs or stages. The design you sketch above
permits 1-RTT discovery at the cost of lesser security. (The service
ID is not encrypted, thereby permitting dictionary attacks as we
discussed.) Bob's proposal addresses this by first doing a mutually
authenticated key exchange and then querying for the service in the
second trip.

While no one was opposed to the two stage approach during the last
meeting, I'm not sure we should rule it out. It depends on the threat
model.

So, having said all that, perhaps someone can take a stab at
documenting the threat model here? That might help us choose a
solution given a shared understanding of the problem. I'm happy to
give it a shot.

Best,
Chris