Re: Comments on draft-dfncis-netnews-admin-sys-06.txt

["Steven M. Bellovin" <smb@research.att.com>]

In message <01L2F77PBGQ400Q4RU@mauve.mrochek.com>, ned.freed@mrochek.com writes
:
>I'm not happy with this document on a number of levels, but my attempts
>to push back on it have not been particularly successful. As such,
>I decided to put this on the agenda so the entire IESG could comment..
>
>Some of the things I've objected are simply poor protocol design choices, such
>as the use of protocol version numbers. I think feature negotiation
>is a better tool to use in application protocols like this. But I don't
>feel comfortable blocking a document based on this sort of thing alone.
>
>IMO security is a much more serious concern. This protocol uses IP address
>validation checks as its primary security tool. THis is hardly surprising give
>n
>that this protocol is a netnews adjunct and this is how netnews is secured muc
>h
>of the time, but I feel that at least the security issues that result
>need to be fully described. But as I said, I haven't been very successful
>in getting this to happen.
>
>In any case, I now have the following set of feedback notes for this
>specification I plan to return to the authors:
>
>  Still no copyright or IPR boilerplate as requested in earlier AD review
>
>  The use of IP addresses for authorization is now mentioned in the security
>  considerations section, but there is still no discussion of the potential
>  problems with this appproach.
>
>  The ABNF rules response-code, Bits, User-ID, Keyblock, Finger, Version,
>  Key-ID, and Location are referenced but never defined.
>
>  References need to be split into normative and informative groups
>
>Additions/clarifications would be appreciated. Thanks.
>

My first reaction to the document was "this is why we have working 
groups rather than relying on individual submissions".  Yes, you're 
100% right.  And it would cost so little to steal the STARTTLS command 
from so many other protocols to protect a password exchange, or to use 
challenge/response.  My tentative candidate for addition to the list is 
poorly-spec'ed use of PGP, though I need to reread it to be sure.

		--Steve Bellovin, http://www.research.att.com/~smb