- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 09 Feb 2010 10:40:27 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Tim <tim-projects@sentinelchicken.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Feb 9, 2010, at 10:08 AM, Adam Barth wrote: > On Tue, Feb 9, 2010 at 6:23 AM, Tim <tim-projects@sentinelchicken.org> wrote: >>> The DNS Spoofing security considerations subsection has a >>> requirement that actually increases the risk of DNS rebinding attacks. >>> It says that "If HTTP clients cache the results of host name lookups >>> in order to achieve a performance improvement, they must observe the >>> TTL information reported by DNS". Clients that follow this advice will >>> be at greater risk than if they give cached DNS lookup results a floor >>> on time-to-live, or keep a DNS resolution result "pinned" so long as >>> any resource from that domain is active. Those are the simplest >>> client-side mitigation strategies for DNS rebinding attacks. If DNS >>> lookups are cached in the browser for a minimum of, say, an hour, >>> there is much less risk of a DNS rebinding attack, because the >>> attacker must get the user to keep a page open for at least an hour to >>> be able to perform the rebinding attack. >> >> While I'm not an expert on DNS rebinding, I'm afraid I don't agree >> that DNS pinning helps prevent rebinding attacks. > > DNS pinning is not a great solution to DNS rebinding, and I would > hesitate to recommend it to user agent implementors. For details, > please see: > > http://www.adambarth.com/papers/2007/jackson-barth-bortz-shao-boneh.pdf I don't necessarily think HTTPbis should recommend it. However, I don't think HTTPbis should make it a MUST-level requirement not to do any DNS pinning, nor claim that following that requirement is necessary for security. > > On the other hand, Host header checking is effective, and it seems > valuable for HTTPbis to recommend it to server implementors. I think that is the important recommendation to add. Regards, Maciej
Received on Tuesday, 9 February 2010 18:41:00 UTC