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

[Paul Wouters <[e-mail]>]

On Wed, 20 Apr 2016, Alissa Cooper wrote:

Hi Alissa,

Thanks for the review. Comments inline,

> I think if this sees any sizable deployment, it will be trivial for
> 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
> 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.

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.

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

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
> about individual queries, it seems like those logs could become prime
> 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
> 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.

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