Re: [dane] [openpgp] The DANE draft

Carsten Strotmann <carsten@strotmann.de> Wed, 05 August 2015 15:36 UTC

Return-Path: <carsten@strotmann.de>
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 57ABB1A0122; Wed, 5 Aug 2015 08:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 COsRkHRi1tm6; Wed, 5 Aug 2015 08:36:44 -0700 (PDT)
Received: from smtp3.strotmann.de (smtp3.strotmann.de [IPv6:2a03:4000:2:33f::5353]) (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 0B2111A013B; Wed, 5 Aug 2015 08:36:43 -0700 (PDT)
Received: from debian01.home.strotmann.de (unknown [IPv6:2a01:198:2b6:1000:240:caff:fea0:83b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id 02DE97FF8B; Wed, 5 Aug 2015 17:36:09 +0200 (CEST)
Received: from Carstens-MacBook-Pro.local (unknown [IPv6:2a03:4000:6:2115::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id 8CB4820005C; Wed, 5 Aug 2015 17:36:08 +0200 (CEST)
Message-ID: <55C22D64.9080507@strotmann.de>
Date: Wed, 05 Aug 2015 17:36:04 +0200
From: Carsten Strotmann <carsten@strotmann.de>
User-Agent: Postbox 4.0.1 (Macintosh/20150514)
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.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>
In-Reply-To: <B7419740-25C9-4F8D-85AE-FC6E11BCC038@vpnc.org>
X-Enigmail-Version: 1.2.3
OpenPGP: id=F7465F6A; url=keys.gnupg.net
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms070201010808000703080608"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/7Q9hOCxiva6R2dprGIVyggZ3CgY>
Cc: IETF OpenPGP <openpgp@ietf.org>, dane WG list <dane@ietf.org>
Subject: Re: [dane] [openpgp] The DANE draft
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 15:36:46 -0000

Hello Paul,

Paul Hoffman wrote:
> Wearing my author hat: I don't care between b32 and hashing. Both are
> equally easy to document. However:
> 
> On 5 Aug 2015, at 4:28, Stephen Farrell wrote:
> 
>> So sorry to continue an argument but shouldn't this experiment be
>> a more conservative about privacy just in case it ends up wildly
>> successful?
> 
> How is using the hash more conservative about privacy, except in zones
> that are signed with NSEC instead of the more common NSEC3? If you
> assume zones signed with NSEC3, both options are equally susceptible to
> dictionary-based guessing attacks, given that the effort to create
> search dictionaries for the billion of common LHS names is pretty low
> even for hashes.
> 

for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use
NSEC/NSEC3 "narrow" signing to prevent "zone-walking".

The issue is more in the DNS query logs. My experience from working with
many DNS-admins over the last decade tells me:

DNS-Admins that could/would snoop into DNS-query logs by creating a
small Perl script to decode the email addresses seen in the logs.

Less DNS-Resovler Admins would go all the way of breaking hashes either
using dictionary-based guessing attacks or a rainbow table.

Breaking hashes requires much more "willful intent" than decoding BASE32.

The hashing communicates a "don't go here" message, even though it is
technically not a strong protection.

It is like having a closed door vs. no door at all. No door communicates
"come in, no secrets, we're open" while the closed door (even if it can
be opened by minor force) communicates "private space".

Best regards

Carsten