- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Feb 2008 11:03:19 +1100
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Henrik, I think I agree, although I'd personally like to see the language advocating some use of caches / TTLs preserved -- in the past it's been very annoying to have browsers cache DNS for the length of a session when you want to do DNS-based failover / round-robin. This is now <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/100>. On 09/08/2007, at 10:42 PM, Henrik Nordstrom wrote: > Been reading and thinking a bit more on the DNS binding problem after > the reminder by Lisa, and came to the conclusion that RFC2616 > recommendations and actual implementation and security concerns is > quite > far apart on this. > > RCF2616 15.3 "DNS Spoofing" recommends the exact opposite of DNS > binding. Any client implementing those recommendations is quite > vulnerable to the discussed issues. This makes me wonder if 15.3 > perhaps > should be dropped from the specifications. Not many user-agents is > following the recommendation found there (certainly none of the main > browser vendors), and it's recommendations also is not very effective > against what 15.3 tries to protect from (DNS poisoning). The > protection > from DNS poisoning 15.3 tries to achieve is best addressed at the DNS > resolver layer, not HTTP application implementation. > > The recommendations in 15.3 is sane from a technical perspective, and > also close to obviously "correct" from a technical perspective, but > unfortunately opens a information theft security issue by using > scripting capable user agents using hostname based access checks to > jail > the executed scripts. So having this in the specs is counter to actual > implementation experience. > > Additionally viewing 15.3 as a security measure is imho not very > useful > as it doesn't really improve the security aspects by any noticeable > amount at any level. > > So in the end it's better to leave this to implementation detail I > think, leaving it out of the protocol specifications I think. > > But this said, the HTTP solution of not allowing servers to answer > requests for "other" sites do solves quite a lot of the security > concerns regarding information theft using HTTP. The rest is client > implementation details to ensure active content is properly jailed. > > Regards > Henrik -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 28 February 2008 00:03:29 UTC