[NNTP] Re: Comments on draft-ietf-nntp-tls-nntp-05.txt

[Ken Murchison]

EKR wrote:

> I just reviewed draft-ietf-nntp-tls-nntp-05.txt. I see that it's
> in Last Call Requested, so consider these some early LC
> comments:

Thanks for the feedback.  I can't really disgree with any of your 
points, but FWIW, we used RFC 3207 and RFC 3501 as templates for this 
document and most of the text you quote was taken directly from them. 
I'll certainly try to clean it up based on your comments.

> 
> S 2.2.2.1 reads:
> 
>      If the NNTP client decides that the level of authentication or
>      privacy is not high enough for it to continue, it SHOULD issue a
>      QUIT command immediately after the TLS negotiation is complete.  If
>      the NNTP server decides that the level of authentication or privacy
>      is not high enough for it to continue, it SHOULD either reject
>      subsequent restricted NNTP commands from the client with a 483
>      response code (possibly with a text string such as "Command refused
>      due to lack of security"), or reject a command with a 400 response
>      code (possibly with a text string such as "Connection closing due
>      to lack of security") and close the connection.
> 
> I don't understand how this happens. TLS includes a negotiation mechanism.
> Implementations shouldn't offer ciphersuites that they aren't willing to
> accept when they complete. If you mean that you get a certificate
> that you subsequently decide you don't like, that's a slightly 
> different issue and I think deserves special discussion.

Agreed on the cipher point.  I think we're more interested in the 
certificate here.


> So, in practice you can saturate a GigE line with SSL/TLS traffic without
> too much effort. If we assume that you use the fastest algorithm: RC4/MD5,
> you see a 4x performance improvement removing RC4. However, if you
> are using SHA-1 (as is current recommended practice) you only get a
> factor of 2, which isn't that impressive. I would generally avoid
> encouraging WGs to advise people to turn off encryption for performance
> reasons. 

Coming from the email world, I tried to argue this same point, but was 
told that given the sheer volume of NNTP traffic, using TLS for an 
entire session is unrealistic in the real world.  Feel free to search 
the list archives or renew this discussion.

Here's a little background on how/why this text creeped into the document:

A lot of newsservers pass authentication off to a secondary server (e.g. 
Radius), thus require plaintext passwords to be recoverable by the NNTP 
server as part of the authentication.  Currently, the only way to do 
this (in the absence of some new SASL mechanism) is the use a of 
plaintext authentication mechanism like SASL PLAIN.  It is my 
understanding that the IETF/IESG won't permit such type of 
authentication in protocols without some type of privacy layer 
protecting the password, so we're required to mandate TLS+PLAIN. 
Admins/developers of large NNTP sites squirmed at this and wanted a way 
to only protect the password and not the *entire* session.

Downgrading the cipher seemed to be one way to accomplish this, but I 
think we're going to invent (most likely resurrect) a new SASL mechanism 
which suits the needs of the community.  In a nutshell, I think the text 
to which you refer can be removed.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp