Opened 15 years ago

Closed 12 years ago

Last modified 12 years ago

#100 closed design (wontfix)

DNS Spoofing / DNS Binding advice

Reported by: mnot@… Owned by: mnot@…
Priority: normal Milestone: unassigned
Component: p1-messaging Severity: Active WG Document
Keywords: security dns rebinding spoof Cc:


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.

Change History (9)

comment:1 Changed 15 years ago by mnot@…

  • Component changed from non-specific to p1-messaging

comment:2 Changed 13 years ago by mnot@…

  • Keywords security dns rebinding spoof added
  • Priority set to normal
  • Severity set to Active WG Document

comment:4 Changed 12 years ago by mnot@…

  • Owner set to mnot@…

comment:5 Changed 12 years ago by mnot@…

AIUI DNS pinning / binding is no longer considered adequate; current advice is to make sure you check Host headers on incoming requests.

HTTPbis could help here by cautioning clients against allowing modification of the Host header when generating requests.

comment:6 Changed 12 years ago by mnot@…

p1 4.2 requires

  1. If the host as determined by rule 1 or 2 is not a valid host on

the server, the response MUST be a 400 (Bad Request) error message.

Is this adequate? If so, does the security implication need to be specifically highlighted (either here or in security considerations)?

comment:7 Changed 12 years ago by mnot@…

  • Resolution set to wontfix
  • Status changed from new to closed

Seems to be agreement that it's difficult to make specific recommendations that will stand the test of time. Furthermore, there were no proposals for text to generally warn about this problem, so closing as WONTFIX. Can reopen if a proposal is made.

comment:8 Changed 12 years ago by julian.reschke@…

From [1369]:

rewrite DNS spoofing advice section, taking Henrik's text (see #100)

comment:9 Changed 12 years ago by julian.reschke@…

From [1370]:

rewrite DNS spoofing advice section, remove unused reference (see #100)

Note: See TracTickets for help on using tickets.