Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
Daniel KAISER <daniel.kaiser@uni.lu> Fri, 08 March 2019 15:57 UTC
Return-Path: <prvs=963d95a02=daniel.kaiser@uni.lu>
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 338631313E0 for <dnssd@ietfa.amsl.com>; Fri, 8 Mar 2019 07:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni.lu
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 t5pHlNax4omA for <dnssd@ietfa.amsl.com>; Fri, 8 Mar 2019 07:57:04 -0800 (PST)
Received: from smtp1.uni.lu (smtp1.uni.lu [IPv6:2001:a18:a:c5::d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758B8131307 for <dnssd@ietf.org>; Fri, 8 Mar 2019 07:57:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni.lu; i=@uni.lu; q=dns/txt; s=DKIM; t=1552060623; x=1583596623; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=zTpRndO5UEztrArEAOV6Jl4O/dd3iZX0M/C0KbxKjvA=; b=jMTGwOXFA9YZJuaOeKUYfNa2RZsgAI0RAIzTtm0uiB34c34/p8ZPElyi Sslrov7nCT3wTsDCSoiOVGtMrEu0CkVzc5EX5YnTXwx5ux8HCFFafQk5E MiXZnkX+y9G1wWfywM38kjiHlN/Cnsx6A8vGUANmOH41F+p0jJ5mndXao DQJBD9wHNPGnuZlBIAwxgYiCbmJJw7tW1pox6/15pVjMAMM55vJ8J/wep y8x0RBtUwbCroGxD2yJrC4UH5LkLYBFFj44XyFUZ8a5Exnyg6+WXGriiy niI95JeNhGPS6yVjpxxi5CAH4Bo8rH7dMLVSBsa+prFRWAOI921sepAUQ Q==;
Authentication-Results: smtp1.uni.lu; spf=Fail smtp.mailfrom=daniel.kaiser@uni.lu; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none) d=uni.lu
X-IronPort-AV: E=Sophos; i="5.58,456,1544482800"; d="scan'208,217"; a="19807577"
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@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@huitema.net> <CAO8oSX=77_s+Fsog4P221v6gQ6TizAfzftivmf2HP=esg6wyHQ@mail.gmail.com> <ad5a0341-6389-f1a9-7b30-4f57feae6745@huitema.net>
From: Daniel KAISER <daniel.kaiser@uni.lu>
To: Christian Huitema <huitema@huitema.net>, christopherwood07@gmail.com, bradley@apple.com
CC: dnssd@ietf.org, dschinazi.ietf@gmail.com
Message-ID: <f0a978ff-39e2-b3fd-ae64-a284a36bc9fc@uni.lu>
Date: Fri, 08 Mar 2019 16:56:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <ad5a0341-6389-f1a9-7b30-4f57feae6745@huitema.net>
Content-Type: multipart/alternative; boundary="------------AEAE110476481A886F8EECA2"
Content-Language: en-US
X-Originating-IP: [10.240.10.16]
X-ClientProxiedBy: Widow2017.uni.lux (2001:a18:a:90::71) To lydia2017.uni.lux (2001:a18:a:90::83)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/jutb0-jgxdIbnhWn8bzQmCuJZcs>
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: Fri, 08 Mar 2019 15:57:19 -0000
Regarding public keys and directory attacks: If we would use *pairwise* symmetric keys instead of "secret" public keys, such directory attacks could not be run efficiently, and we could use hinting to avoid trial decryption. The draft on bloomfilter hints I posted would be a first step towards making pairwise-key-based discovery more efficient in terms of discovery messages needed. Further, as discussed before, using pairwise keys, clients that use a service cannot infer which other clients use the same service; and a leaked key only affects a single pair of client and server. Pairing: For establishing the pairwise keys, we could use (and build on) the mechanism described in draft-ietf-dnssd-pairing-05. If we stick to "secret" public keys, how do we distribute the public keys to authorized clients? (I also agree that we should not refer to these keys as public keys.) Kind regards, Daniel Kaiser On 2/28/19 7:03 PM, Christian Huitema wrote: > > > On 2/27/2019 10:25 PM, Christopher Wood wrote: >> >> >> On Wed, Feb 27, 2019 at 9:43 PM Christian Huitema >> <huitema@huitema.net <mailto:huitema@huitema.net>> wrote: >> >> On 2/27/2019 8:15 PM, Christopher Wood 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. >> >> >> Right! That confirms what I said above. Thanks for clarifying. > > And thanks for clarifying the dictionary attack concern. I was blinded > by the "all bets are off" assumption. If the discovery key of the > service is known by attackers, then the attackers can detect the > presence of the service in a local network. They indeed can, but all > bets are not off. The attackers have to mount an active attack. They > have to attempt a discovery and see whether the service is present and > replies. If we use hints, they can perform a passive dictionary > attack, e.g. browsing logs of traffic and detecting whether the > service was present. The all bets are off assumption is wrong, we have > to think of defense in depth. > > Bottom line, the ESNI based solution should use a static proforma > "record_digest", or no record digest at all. No hints, just use trial > decryption, like Bob proposed. > > If we become concerned about the cost of trial decryption, we can > start playing with time windows. Many scenarios have a "meeting" > structure, "A meets B and they discover each other". We can arrange > mitigations around that, e.g. only perform trial decryption when the > app is actively waiting for connections. > > -- Christian Huitema > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd -- Dr. Daniel Kaiser Research Associate SnT- Interdisciplinary Centre for Security, Reliability and Trust University of Luxembourg Maison du Nombre (MNO) 6, avenue de la Fonte L-4364 Esch-sur-Alzette Office: E02 0225-010
- [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