Re: [dane] [openpgp] The DANE draft

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 05 August 2015 18:33 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D2E1B3446 for <dane@ietfa.amsl.com>; Wed, 5 Aug 2015 11:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 DNa-AIXuyOhx for <dane@ietfa.amsl.com>; Wed, 5 Aug 2015 11:33:25 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121D11B3458 for <dane@ietf.org>; Wed, 5 Aug 2015 11:32:48 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 07218284D68; Wed, 5 Aug 2015 18:32:47 +0000 (UTC)
Date: Wed, 05 Aug 2015 18:32:46 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150805183246.GQ19228@mournblade.imrryr.org>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com> <87bnf1hair.fsf@alice.fifthhorseman.net> <alpine.LFD.2.11.1507250832510.854@bofh.nohats.ca> <87bnem2xjq.fsf@alice.fifthhorseman.net> <alpine.LFD.2.11.1508050331340.1451@bofh.nohats.ca> <55C1F35A.5070904@cs.tcd.ie> <B7419740-25C9-4F8D-85AE-FC6E11BCC038@vpnc.org> <55C22AD4.5010709@cs.tcd.ie> <DB1E53C6-11DF-4194-852D-776B670E2409@vpnc.org> <55C23B3D.1030502@posteo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55C23B3D.1030502@posteo.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/194otRw5UaDFTfzJTTzffZW93Jc>
Subject: Re: [dane] [openpgp] The DANE draft
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 18:33:26 -0000

On Wed, Aug 05, 2015 at 06:35:09PM +0200, Patrik L?hr wrote:

> That's the point - we are concerned with on-path watchers.
> That is why we are in strong favour of hashing like I already stated:
> Hashing does not protect against "decryption" - but it makes a distinct
> difference whether I need to make a targeted attack on a hash, or can
> arbitrarily search through the plaintext in a stream of data.

I don't think hashing (without salt) provides sufficient obfuscation
to deter on-path attacks.  If you're serious about mitigating
on-path passive monitoring of DNS lookups, you MUST not only hash
the localparts, but the hash MUST include a salt.

Building a table of the top few billion localpart names is just
too cheap.

Even with salting, very large domains like gmail.com, ... are still
substantially vulnerable to attack without a reasonably high
iteration count.  However, a high iteration count makes the
construction of the zone data rather expensive.

I don't think  it is possible to construct any reasonable mechanism
that avoids metadata leakage with DNS queries sent in the clear.

If avoiding metadata leakage is important, the lookups need to
happen over TLS or IPsec.  Half-measures that attempt to obfuscate
DNS queries are not IMHO a useful direction to pursue.

The reason I proposed hashing (long ago) was to deal with long
localparts, not enhance privacy.  I did propose including the domain
name in the hash ("breaking" DNAME support, really requiring per
address not per localpart data) to frustrate data recovery by zone
walkers, but that was not about mitigation of on-path metadata
collection.

-- 
	Viktor.