So, as of 0.1.2.0, we're sending back meaningful TTL values for DNS results for the first time. There are some subtle issues, so I'll braindump to the list in hopes that somebody can come up with a better solution. Here's a *bad* solution: the exit server, when asked to resolve an address for a user, remembers the TTL. If asked again later, it returns the original TTL, minus the amount of time that has passed. Here's why that solution is bad: At noon, Alice asks for mildly-embarassing.com; the exit node resolves it, and learns that the TTL is one hour. The exit node tells Alice the answer and "one hour" for the TTL. At 12:21:25, Bob asks for mildly-embarassing.com; the exit node finds the answer in its cache, and sees that it has 39 minutes and 35 seconds left to live. The exit node tells Bob the answer and "39 minutes, 35 seconds" for the TTL. From this, Bob can deduce that somebody asked for m-e.com at noon sharp. If Bob is watching Alice, this may be enough to compromise her. So here's what we're doing instead: Exit nodes tell users the exact TTL they received, even if time has passed, but never cache a DNS result for longer than MIN(TTL, 30 minutes). This means that an attacker can't infer the exact time when a result was requested. This also means that users sometimes receive a stale entry. Is this dumb? Is there something *better* we should be doing instead? (No need to tell us about equally dumb things we could be doing; we know about several of those.) peace, -- Nick Mathewson
Attachment:
pgpmS4FSwatL4.pgp
Description: PGP signature