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: > 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
