[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-------------------------------------------------+-------------------------
Reporter: teor | Owner:
Type: defect | Status:
| needs_information
Priority: Very High | Milestone: Tor:
| 0.3.0.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: 029-proposed, dns, | Actual Points:
TorCoreTeam201609 |
Parent ID: | Points: 0.5
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by pulls):
== Concretely ==
{{{
MIN_DNS_TTL = 5*60;
MAX_DNS_TTL = 60*60;
dns_clip_ttl(uint32_t ttl)
{
if (ttl < MIN_DNS_TTL)
return MIN_DNS_TTL;
else
return MAX_DNS_TTL;
}
}}}
- Fix #19025 (otherwise ttl above will always be MIN_DNS_TTL).
- Potentially refactor the DNS caching code to support evictions (while
doing this, maybe rip out all old client-side DNS caching code?).
- Add some form of logging to track cache size, usage, and eviction rate.
- dns_get_expiry_ttl should be the same as dns_clip_ttl above. Please note
that we are not sure these are the only relevant functions.
== Given ==
- For popular websites, caching at exits is highly likely, and DefecTor
attacks are the same as WF attacks.
- For unpopular websites, caching and TTLs are moot, since the probability
of an DNS record being chached is negligible. Caching these records are
just an extra burden on the exit and in a sense also a risk due to leaking
recent activity at the exit on compromise. DefecTor attacks will be more
precise than WF attacks here, and Tor needs WF defenses to mitigate
(another long-term topic).
- For long TTLs, for what it is worth, we know from #19025 that the real-
world impact of ignoring these long TTLs are not a serious issue.
- For short TTLs, the impact of increasing it is our primary worry since
we might break something.
- We want to prevent fine-grained TTLs to protect against tagging attacks.
- We do not want too high TTLs to have a chance to auto-magically resolve
DNS cache poisoning.
- The total size of the cache might be a vector for DoS.
- The client-side DNS cache remains off.
== Goals for DefectTor mitigation ==
- Allow long TTLs to be long(er).
- For short TTLs, go as far up as we are comfortable to without
significantly risking breaking things.
== Proposal ==
Stage changes: start with repairing the TTL bug #19025 and change clipping
to 5*60 seconds for MIN_DNS_TTL and 60*60 seconds for MAX_DNS_TTL,
honoring no intermediate values (see code above). Wait for feedback on
unexpected breaks. If all manageable, increase MIN_DNS_TTL to 60*60 in a
future patch, effectively always caching for 60 minutes. If DefecTor
attacks become a real concern short-term, encourage concerned site owners
to consider longer TTLs to hit the MAX_DNS_TTL value. Make the cache size
limited and eviction when full uniformly random. We random to give an
attacker less control since it can presumably cause evictions at will
(LIFO is easy to manipulate for an attacker).
Getting feedback on real-world cache size, usage, and eviction rate from
exit operators would be useful, so perhaps some form of log output is
reasonable?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19769#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs