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.
- [dane] Alissa Cooper's No Objection on draft-ietf… Alissa Cooper
- Re: [dane] Alissa Cooper's No Objection on draft-… John Levine
- Re: [dane] Alissa Cooper's No Objection on draft-… Paul Wouters
- Re: [dane] Alissa Cooper's No Objection on draft-… Stephen Farrell