ietf-nntp new Draft available

[Stan O. Barber]

Andrew Gierth wrote:
> 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.


I think they are concerned about both client and server. 

> 
>  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


Thanks. This makes it much easier to make the draft clearer.

> 
>  >> 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.


Your opinion in noted. Let's see what others have to say.

I have no comments on the rest of your note other than to request that you take
a more civil tone in future email.