Re: #100: DNS Spoofing / Rebinding

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.




Regarding the mentioned Host header validation in p1 4.2 #3, that's not
a new requirement. Been there since 2616 at least. And still most
implementations do have a catch-all default directly violating this.


Regards
Henrik

Received on Friday, 29 July 2011 23:13:33 UTC