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: Tue, 02 Aug 2011 14:32:36 +0200
Message-ID: <4E37EE64.1090604@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-31 13:24, Julian Reschke wrote:
> 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?

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1370>...:

11.4.  DNS-related Attacks

    HTTP clients rely heavily on the Domain Name Service (DNS), 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
    ([RFC4033]).


Best regards, Julian
Received on Tuesday, 2 August 2011 12:33:15 GMT

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