ietf-nntp new Draft available

Andrew Gierth andrew at erlenstar.demon.co.uk
Mon Nov 8 12:50:17 PST 1999


>>>>> "Stan" == Stan O Barber <sob at verio.net> writes:

 Stan> Specifically, what of your previous comments were not addressed
 Stan> in the draft?

 [snip of a restatement of my previous comments on PAT]

 Stan> This is on the agenda for discussion today, which is why it is
 Stan> not in the draft.

Exactly, which is why I didn't bother to restate them until you
specifically asked for them!

 >> (This is the first announcement of a draft since I joined this list.)

 Stan> Hmm. I thought it was standard practice for folks to review the
 Stan> current drafts when they join the list.

I read the then-current draft and spent some time in the list archives
before joining the list.

 >> >> The section on DNS spoofing, while it touches on the issue of
 >> >> mismatched forward/reverse lookups, should, IMO, spell out
 >> >> explicitly the requirement that reverse DNS lookups should be
 >> >> confirmed by performing the forward lookup before the returned
 >> >> name is used for either access control or logging or trace
 >> >> information (including trace headers added to posted articles).

 Stan> Hmm. Evidently, those that reviewed the HTTP 1.1 spec didn't
 Stan> see this as an important enough issues since the text here is
 Stan> based on that spec.

OK, I went and looked at the HTTP stuff to see where they were coming
from.

It seems to me that they are more concerned about DNS from the
perspective of the client looking up the server's address; which is
much less interesting from an NNTP perspective.

The problem for NNTP is precisely the reverse. While it is possible
(indeed generally preferable for reader clients) to do access control
by IP address alone rather than by DNS name, it is nevertheless the
case that most deployed server software has the option to do access
control by hostname. Furthermore, at least three widely-used server
implementations (including the original reference implementation) have
been found to be vulnerable to abuse if an attacker with control over
his reverse DNS is able to guess at a hostname which has access to the
server.

 >> It is nevertheless a fact that there are many people who both
 >> control their own reverse DNS and have an active desire to exploit
 >> and abuse NNTP servers, and deceive the administrators of those
 >> servers as to their origins.

 Stan> Okey. So your arguement is effectively that this description
 Stan> does not explicitly point out this specific "spoof"? Providing
 Stan> specific text would make this all much clearer to me.

How about something along these lines:

    Server implementors should bear in mind that the owner of an IP
    address may be able to supply any arbitrary string as the result
    of a reverse lookup (in-addr.arpa.) query on that IP address.
    Accordingly, the result of such lookups should never be used for
    access control, logging, or any other purpose without first
    confirming that a forward lookup on the name resolves back to
    the same IP address.

    Logging and accountability information should use the IP address
    in preference to, or in addition to, the reverse DNS data.

An additional reference is the LINX BCP on traceability, which
can be found at http://www.linx.net/noncore/bcp/traceability-bcp.html

 >> It is also a fact that simple errors in reverse DNS have, in the
 >> past, caused articles to be incorrectly traced and users to be
 >> wrongfully accused of abuses.

 Stan> Tracing information is part of the content of the articles, not
 Stan> part of the protocol spec. This type of comment may belong in
 Stan> the USEFOR spec, not here.

Tracing information is also part of server logs; indeed there is
significant resistance in USEFOR to adding trace information to
articles that should more properly be handled on the originating
server alone.

As you've already introduced the issue of traceability in 14.1,
I don't see any reason to exclude the DNS issue from this draft.

 >> Even if you (quite reasonably) consider spamming, flooding, rogue
 >> cancelling etc. to all be "just the data shipped around by the
 >> protocol", then the wording in the draft is still woefully
 >> inadequate in the face of real-world experience of the level of
 >> abuse which is committed through insecure servers.

 Stan> Again, specific proposals for changes to the text would make
 Stan> this all much clearer. Saying that it is "woefully inadequate"
 Stan> is not very persuasive without a concrete example.

Where the hell have you _been_ for the past couple of years?

The primary reason, IMO, for the virtually continuous stream of abuse
that has been coming from insecure servers over that time is not
incompetent administration (though that is a minor factor) but lack
of care by server software authors with regard to the configuration
of access controls.

Copying text from the HTTP specs is hardly the way to help improve
matters; HTTP servers rarely talk to each other, whereas NNTP servers
almost always do so. An insecure HTTP server inconveniences no-one
but its owner; an insecure NNTP server inconveniences not only its
owner but also the entire set of servers with which it directly or
indirectly exchanges feeds.

-- 
Andrew.



More information about the ietf-nntp mailing list