On Wed, Apr 6, 2016 at 6:03 AM, Daniel Kahn Gillmor <[email protected]> wrote: > > forward secrecy > --------------- > > IIUC for (b), the failing forward secrecy window is constrained by the > duration of the PSK/session resumption ticket. That's doesn't seem > particularly worrisome to me for DNS. >
I'd expect many operators to re-use ticket encryption keys for far too long, as we see with HTTPS today, so the effect is that a dns server bug may unlock years of 0RTT data. For DNS, the query is always likely to fit in there. > replay protection > ----------------- > > For DNS we don't particularly care about replay attacks initially, but > replayable traffic might have some privacy implications. > > For example, if Mallory can monitor the traffic to and from the DNS > resolver, and a TLS-wrapped DNS request is made that is answered from > the cache, then the attacker has no additional information about what > the answer is. > > But if the request is replayable, Mallory can capture it, and replay it > at different intervals (when parts of the cache might be expired) to try > to coax the recursor to call out to the authoritative resolvers, which > might provide more information about the original query. > There's a simpler attack too; if the RRSet contains multiple RRs, it's common for resolvers to rotate the order of the RRs in a fixed and predictable order. So you can query a name you suspect was queried, then replay the target query, then query the name again, and confirm your suspicion. This requires only a copy of the target 0RTT section, and access to query the resolver, so a typical wifi scenario would do. Multi-RR responses are very common these days too. -- Colm
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
