W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #100: DNS Spoofing / Rebinding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 31 Jul 2011 13:24:41 +0200
Message-ID: <4E353B79.9080205@gmx.de>
To: Henrik Nordström <henrik@henriknordstrom.net>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Lisa Dusseault <lisa.dusseault@gmail.com>
On 2011-07-30 01:12, Henrik Nordström wrote:
> sön 2011-07-17 klockan 11:33 +1000 skrev Mark Nottingham:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/100>
>>
>> We've had this ticket open for a while now.
>>
>> Relevant text in our current draft:
>>    <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-11.4>
>>
>> AIUI DNS pinning is no longer considered an adequate defence against
>> rebinding, and the current advice is for servers to verify the Host
>> header.
>
> Regarding issue #100, I think it's a proper action to align
> specifications with current implementations a bit by dropping the MUST
> level requirement from p1 11.4, deleting the following text entirely:
>
>     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.
>
>     If HTTP clients do not observe this rule, they could be spoofed when
>     a previously-accessed server's IP address changes.  As network
>     renumbering is expected to become increasingly common [RFC1900], the
>     possibility of this form of attack will grow.  Observing this
>     requirement thus reduces this potential security vulnerability.
>
> with no replacement or other changes to the text. Leaving it entirely up
> to implementations how they cache DNS lookups if they cache. The other
> requirements are all SHOULD level leaving the door open to cache if one
> want's to.
>
> As already noted the section in general is both bad advice in terms of
> security and the opposite of what most client implementations do today.
> And in issues like this it's better to be silent than to give bad
> advises.
>
> But even with this text deleted the title of the section is questionable
> except for the initial paragraph.
>
> For domains using DNSSec the situation is quite different. There
> everything said in p1 11.4 is true, secure and technically correct. But
> then the title is completely irrelevant.
>
>
> So here is another proposal. Shorten and rewrite p1 4.2 as follows
>
>          Clients using HTTP rely heavily on the Domain Name Service, and
>          are thus generally prone to security attacks based on the
>          deliberate misassociation of IP addresses and DNS names not
>          protected by DNSSec. Clients need to be cautious in assuming the
>          validity of an IP number/DNS name association unless the
>          response is protected by DNSSec.
>
>
> removing all advices on how to (not) to cache DNS responses or any
> implications that there is any continuing relation. And in lack of a
> usable reference keep silent on the bit of how to be cautious.
> ...

Sounds good -- but that's for 11.4, not 4.2, right? Also, do we need a 
new section title? "DNS-related Attacks"?

Finally, we'll need a ref for DNSSec. RFC 4033?

Best regards, Julian
Received on Sunday, 31 July 2011 11:25:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:46 GMT