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

Daniel KAISER <> Fri, 08 March 2019 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 338631313E0 for <>; Fri, 8 Mar 2019 07:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5pHlNax4omA for <>; Fri, 8 Mar 2019 07:57:04 -0800 (PST)
Received: from ( [IPv6:2001:a18:a:c5::d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 758B8131307 for <>; Fri, 8 Mar 2019 07:57:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; 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:; spf=Fail; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none)
X-IronPort-AV: E=Sophos; i="5.58,456,1544482800"; d="scan'208,217"; a="19807577"
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Daniel KAISER <>
To: Christian Huitema <>, <>, <>
CC: <>, <>
Message-ID: <>
Date: Fri, 8 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: <>
Content-Type: multipart/alternative; boundary="------------AEAE110476481A886F8EECA2"
Content-Language: en-US
X-Originating-IP: []
X-ClientProxiedBy: Widow2017.uni.lux (2001:a18:a:90::71) To lydia2017.uni.lux (2001:a18:a:90::83)
Archived-At: <>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.

For establishing the pairwise keys, we could use (and build on) the 
mechanism described in
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 
>> < <>> 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


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