W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: New issue: 15.3 misguided?

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Feb 2008 11:03:19 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <78B462E5-8386-4115-8453-CE46E837CD10@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC