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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 20 Apr 2016 14:45:45 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-dane-openpgpkey-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I know there has been a lot of list discussion of this draft so I
apologize if these issues have already been discussed before.

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 also think the mechanism could facilitate pervasive monitoring as
described in RFC 7258, as it potentially makes a whole class of entities
(resolvers) into repositories of detailed data about who has communicated
with whom via email. To the extent that large DNS providers keep logs
about individual queries, it seems like those logs could become prime
attack targets. The mechanism specified here can obviously help mitigate
pervasive monitoring in other ways, but I think the draft needs to be up
front about the trade-offs between potentially exposing metadata to a
wider pool of entities and attackers in exchange for more easily being
able to protect content.

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2016 00:01:53 -0000

>to say that by using this mechanism, people are effectively making their

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.

>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.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Apr 2016 10:06:49 -0400 (EDT)

On Wed, 20 Apr 2016, Alissa Cooper wrote:

Hi Alissa,

Thanks for the review. Comments inline,

> attackers to use it to harvest email addresses from the DNS.

Email addresses when used area really hard to keep secret. See also
John's remarks on this. This just moves the online-smtp attack to an
online-dns attack. Not that different.

> Section 7.4

Why send a DNS query for a hashed name when you can send a probe to the
SMTP server?

The only additional issue is that one could zonewalk to harvest the
records, then perform an offline dictionary attack. But with DNSSEC
white/black lies with an online signer these could be mitigated. One could
even add records of non-existing users to bump the failure rate similar
to John's described defense of always claiming any email address is valid.

> with whom via email.

One could argue this deployment will actually more decentralise this.
When a pervasive monitor sees an OPENPGPKEY query from 8.8.8.8 it knows
less then if it sees a HTTP/HTTPS connect from some ISP owned DSL IP to
a keyserver IP address. A pervasive monitor would also be able to keep
track of that DSL IP and figure out the target domain or even target
user at the domain. Match that with keyserver contents and TLS traffic
size, they could pinpoint who you obtained a key for even if everything
between keyserver, user and SMTP was protected by TLS.

Currently, the only somewhat automated method is to query well known
key servers or a search engine. There are only very few of these so much
easier to pervasively monitor. For keyservers, I tend to use pgp.mit.edu
and pgp.surfnet.nl. Both accept HTTP without redirect to HTTPS. One of
them even does not work on HTTPS.

> To the extent that large DNS providers keep logs
> attack targets.

DNS is gaining protection with both DNS-over-TLS and Query
Minimalization. Endusers can pick DNS servers they trust.

> The mechanism specified here can obviously help mitigate

In fact, using the DNS and caches and a method of securely querying the
DNS from any point on the network actually gives you a nice and good
pool of anonimity required to hide. I would not know of a better method
to do that currently. For instance, using TOR for DNS.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Apr 2016 15:12:01 +0100

Hi Paul,

On Alissa's 2nd point, I think there might be a useful sentence
or two to add about the PM-relevant trade-offs between this approach
and others, (if we can ensure those sentences aren't inflammatory:-).
Do you think we could craft something along those lines to include?

Cheers,
S.

On 21/04/16 15:06, Paul Wouters wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane