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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 28 February 2019 14:28 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 A2932130E91 for <dnssd@ietfa.amsl.com>; Thu, 28 Feb 2019 06:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 aqjRQIrHFZmw for <dnssd@ietfa.amsl.com>; Thu, 28 Feb 2019 06:28:54 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05C7130E9C for <dnssd@ietf.org>; Thu, 28 Feb 2019 06:28:54 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 82AB33826A; Thu, 28 Feb 2019 09:28:47 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 3BE29D63; Thu, 28 Feb 2019 09:28:53 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3A5D25D; Thu, 28 Feb 2019 09:28:53 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Christian Huitema <huitema@huitema.net>
CC: dnssd@ietf.org
In-Reply-To: <a6357d59-fb6f-3129-2e7f-a77cfff9c145@huitema.net>
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@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> <CAO8oSX=rWYxkKq0H5dEJDKq_Hs3tH2gqSxQ-Cr_SaHDPkrvvCA@mail.gmail.com> <CAO8oSXkfszNXUT6gr1G2OEWgJXe-cX_S4yAJmLm5sUqN0SQ54w@mail.gmail.com> <CAPDSy+7UvYdNOeYZg-R2b+eXuvGNMguXDWtkKgotVpLP5YPk4g@mail.gmail.com> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <CAO8oSX=9Fi60GigVWgCRkLXxwgF8aD1BveVNicz6_m5S-MQnYg@mail.gmail.com> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> <CAO8oSXmKwA6yE3A_OczjCBSvLwm1jqT3dEDNGzAB88ZM785+CQ@mail.gmail.com> <eb11a426-fcf5-7e62-6b40-82f5218e1d47@huitema.net> <CAO8oSXkMc1RL7YBfmNx4teShO9BCT_FAvcXc5hatahDd-17uhg@mail.gmail.com> <a6357d59-fb6f-3129-2e7f-a77cfff9c145@hui tema.net>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Thu, 28 Feb 2019 09:28:53 -0500
Message-ID: <5847.1551364133@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/dmO1LRzNHg-OhUGeJqmNHDwlEeo>
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 14:28:57 -0000

Christian Huitema <huitema@huitema.net> wrote:
    >> Okay, so, as I suspected, this is vulnerable to dictionary attacks if
    >> the public key is leaked. Am I misunderstanding? If so, can you
    >> explain why this is not the case?

    > If the public key is leaked, anyone with the leaked key can impersonate
    > an authorized client, establish a connection, etc. The secrecy of the
    > public key is what keeps this together. In all these schemes, there has
    > to be a secret that acts as the seed for the privates exchanges, and in
    > the scheme I propose that secret is the public discovery key of the server.

Since we have extensive public training that the "public key" is safe to
disclose, this may be confusing for many, as this is no longer the case for this.

May I suggest different terminology?  As the two halves of asymmetric keying
systems are mathematically equivalent, so maybe we could call it the
client-dual-key or something like that.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-