Re: [dane] Alissa Cooper's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT)

"John Levine" <johnl@taugh.com> Thu, 21 April 2016 00:02 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BC312EE1B for <dane@ietfa.amsl.com>; Wed, 20 Apr 2016 17:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ppdaomt2GmOl for <dane@ietfa.amsl.com>; Wed, 20 Apr 2016 17:02:17 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5552912EE1A for <dane@ietf.org>; Wed, 20 Apr 2016 17:02:17 -0700 (PDT)
Received: (qmail 82396 invoked from network); 21 Apr 2016 00:02:15 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2016 00:02:15 -0000
Date: Thu, 21 Apr 2016 00:01:53 -0000
Message-ID: <20160421000153.18739.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: dane@ietf.org
In-Reply-To: <20160420214545.800.62731.idtracker@ietfa.amsl.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/lyFbNvPwyOuUA-eSNgdwnXV-70I>
Cc: alissa@cooperw.in
Subject: Re: [dane] Alissa Cooper's No Objection on draft-ietf-dane-openpgpkey-10: (with COMMENT)
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 21 Apr 2016 00:02:18 -0000

>I think if this sees any sizable deployment, it will be trivial for
>attackers to use it to harvest email addresses from the DNS. Section 7.4
>therefore seems to be quite misleading. I don't see why a zone walk is
>necessary to do this kind of harvesting when an attacker could just send
>one query per entry in its dictionary. I think it would be more accurate
>to say that by using this mechanism, people are effectively making their
>email addresses public.

I think this draft is a bad idea and should not be published at all,
but that isn't one of the reasons.

Address harvesting has been a problem for decades, since anyone can do
a partial SMTP transaction up to the RCPT TO stage to verify
addresses.  There are even companies that will check lists of
addresses for you to try and weed out the invalid ones.

Countermeasures are widely known in the e-mail community.  The obvious
one is rate limiting, but it turns out that a more effective one is to
lie and say all addresses are valid (in this case by returning fake
but plausible certificates.)  We often see the validation places start
by probing a bunch of random made up addresses to see if a domain says
yes to everything and then give up when it sees that we do.

>I also think the mechanism could facilitate pervasive monitoring as
>described in RFC 7258, ...

That, on the other hand is a problem: this draft has no security model
beyond saying it's not the web of trust.  With SMTP address probes, the
target system has some idea who it's talking to, and can require TLS
to prevent third parties from observing the traffic.  With DNS, the
traffic all goes unencrypted via caches.  The caches are often not
under the same management as the end system, and caches routinely
provide data to third parties for forensic and other purposes.  See,
for example, Farsight Security, run by people we all know, which
provides a large and interesting database of DNS query traffic to its
clients who use it to track down various sorts of online badness.

Everything published in the DNS has traditionally been public.  Some
people imagine that the contents of their zone files are proprietary,
but we know they're silly.  Publishing information that's
semi-private, or that contains PII, is a significant change of DNS semantics,
and its implications need far more careful evaluation than this
draft does.

R's,
John

PS: It also has downgrade problems, see prior messages on that topic.