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

[Stephen Farrell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane