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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
