> On May 23, 2017, at 12:52 PM, Christian Huitema <huit...@huitema.net> wrote:
>
> Colm's point is that for many DNS servers, queries are not truly stateless.
> The answer to a query for AAAA records for example.net might vary over time,
> or even query to query, for example to manage load balancing. Adversaries can
> predict these variations. They can observe the state of the server before and
> after replaying 0-RTT data. If they observed that the 0-RTT data caused the
> answer to change, they can confirm that the 0-RTT data contained a request to
> that server.
The fix is to amend DNSpriv to require stateless (random rather
than say round-robit) RRset rotation. With random rotation, the
next RRset order is independent of previous queries.
Secondly, even with the 0-RTT leak, while privacy against an active
attacker might not be assured for all users, there is fact privacy
for most users, especially against a purely passive adversary.
DNS privacy is always an imperfect security mechanism because
the DNS query will often at in the provider request to the
authoritative servers leak the user's "subnet" in the clear,
typically in the form of the containing /20 CIDR block to aid
load-balacing CDNs. Then after the response is received, the
client will send IP datagrams that further narrow the set of
potential domains. Then in visiting a website there'll be
unencrypted SNI, or predictable patter of response sizes and
consequent retrieval of CSS/javascript/image resources that
fingerprint the request.
Cryptography and 0-RTT are far from the weakest link in the
chain here. DNSpriv is necessarily imperfect incremental
security, and defeating traffic analysis is exceedingly
difficult.
To the extent that DNSpriv over TLS happens at all, 0-RTT
will be used for DNS, and will be used statelessly (allowing
replays). If there are sufficiently cheap ways to improve
security (e.g. random RRset rotation) without sacrifing
performance, increasing latency or adding complexity, then
by all means promote their adoption.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
