On Wed, Aug 05, 2015 at 06:35:09PM +0200, Patrik L?hr wrote:
> That's the point - we are concerned with on-path watchers.
> That is why we are in strong favour of hashing like I already stated:
> Hashing does not protect against "decryption" - but it makes a distinct
> difference whether I need to make a targeted attack on a hash, or can
> arbitrarily search through the plaintext in a stream of data.
I don't think hashing (without salt) provides sufficient obfuscation
to deter on-path attacks. If you're serious about mitigating
on-path passive monitoring of DNS lookups, you MUST not only hash
the localparts, but the hash MUST include a salt.
Building a table of the top few billion localpart names is just
too cheap.
Even with salting, very large domains like gmail.com, ... are still
substantially vulnerable to attack without a reasonably high
iteration count. However, a high iteration count makes the
construction of the zone data rather expensive.
I don't think it is possible to construct any reasonable mechanism
that avoids metadata leakage with DNS queries sent in the clear.
If avoiding metadata leakage is important, the lookups need to
happen over TLS or IPsec. Half-measures that attempt to obfuscate
DNS queries are not IMHO a useful direction to pursue.
The reason I proposed hashing (long ago) was to deal with long
localparts, not enhance privacy. I did propose including the domain
name in the hash ("breaking" DNAME support, really requiring per
address not per localpart data) to frustrate data recovery by zone
walkers, but that was not about mitigation of on-path metadata
collection.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
