Re: [dane] OPENPGP --- Privacy considerations

[Viktor Dukhovni <[e-mail]>]

On Sat, Aug 01, 2015 at 03:16:04PM +0200, Florian Kirstein wrote:

> Did you read my full email? Thats EXACTLY what I wrote in a later
> paragraph. And it's the reason I wrote I vote for sha. And even would
> prefer iterations there %) And see the risk of rainbow tables used
> to reverse those.

My original proposal that introduced hashes for the local part
suggested hashing the full email address to help thwart rainbow
tables.  That was not accepted, because it does not support domain
equivalence via DNAME aliases.  And we've failed to reach consensus
on even a single layer of hashing just the local part.  There is,
however reluctant, some consensus around base32.

No matter what storage encoding of the localpart is used, a passive
wiretap will reveal the domain of each correspondent's key lookup,
and whether that correspondent is new or one that was looked up
previously.  This is inherent in using a cleartext DNS query
protocol.

How important is support for such equivalent domains, relative to
potential privacy gains?  There is no privacy for lookups of DNS
data, until the transmission channel is somehow encrypted, but even
then, unless your local resolver avoids forwarding all queries to
the ISP, the ISP resolver has the plaintext of all DNS queries.

There was some recent discussion of

    https://tools.ietf.org/html/draft-moore-email-addrquery-01

on the IETF UTA list.  As written in that draft the MSA learns the
plaintext of all key lookups, but this is not a data leak, because
in short order the MSA will see the envelope of the final outbound
message.  With STARTTLS on increasingly more SMTP hops, localpart
data is modestly well protected (passive wiretaps may be able to
distinguish between long and short envelope recipient addresses
based on the sizes of TLS packets unless random padding is used to
extend such packets to hide the plaintext length).

Protection from traffic analysis requires Tor (or better).

So trade-offs are inevitable, and evidently make reaching consensus
difficult.

In the UTA discussion, I am running into irrational fear of DNSSEC,
and I think an unreasonable goal of eliminating the MSA as a trusted
party.  Always using the MSA as a proxy would I believe significantly
improve the scalability and abuse resistane of the protocol.
Without the complexity of end-to-end payload signing, the MSA would
need to be trusted.  It may be possible to add end-to-end signing,
but not clear how without DANE publishing the signing keys, and
stapled DANE responses between MUA and MSA.

Given the clear DNSSEC animus of at least some of the parties, I
don't see a way forward that avoids compromising at least one of
the objectives.  Time will tell...

These are not easy to solve problems.  If someone thinks they have
a simple solution that does not compromise on any of the design
goals, they're probably not thinking hard enough.

-- 
	Viktor.