[NNTP] Re: Comments on draft-ietf-nntp-tls-nntp-05.txt
ken at oceana.com
Tue May 24 11:14:19 PDT 2005
> 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
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 220.127.116.11 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
> 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
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
More information about the ietf-nntp