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

From: Daniel KAISER <[email-masked]>
Date: Fri, 8 Mar 2019 16:56:58 +0100

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 
>> <[email-masked] <mailto:[email-masked]>> 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
> [email-masked]
> 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