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

[Andrew Gierth]

>>>>> "EKR" == EKR  <ekr at networkresonance.com> writes:

 > Russ Allbery <rra at stanford.edu> wrote:
 >> EKR <ekr at networkresonance.com> writes:
 >> > Ken Murchison <ken at oceana.com> wrote:
 >> >> 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.
 >> 
 >> > Yes, I recall repeated vigorous assertions to this effect,
 >> > combined with fairly small amounts of data.
 >> 
 >> I believe Andrew Gierth had concrete data in this area.

 EKR> I'd be interested in seeing it. 

Well, nondisclosure limits how much I can say, but it's unquestionably
true that (a) traffic levels of many gigabits are the norm rather than
the exception in the commercial Usenet provider industry (which is a
very significant user of authenticated NNTP connections, and more
importantly also has a major effect on client development) and (b) the
CPU cost of encrypting all that, purely to protect the password, is
not something that can simply be absorbed.  There are also no
indications that any significant proportion of users are prepared to
pay a price premium to have encryption for the entire session.

 >> Note that one of the reasons why encryption gets odd reactions
 >> from the NNTP community is that, unlike e-mail, all of the data
 >> except for the authentication is public in some of our most common
 >> use cases.  This is not, itself, a reason to not do encryption
 >> (the performance impact is really the thing to worry about), but
 >> it feels intuitively weird to bother encrypting the contents of
 >> public Usenet hierarchies.

 EKR> Sure, but now we're into the "is this a worthwhile optimization"
 EKR> phase. 

 EKR> There's a substantial complexity cost to having SSL/TLS
 EKR> implementations rehandshake. If you just wanted to do NULL all
 EKR> the time, I'd have no real argument with that. It's the desire
 EKR> to negotiate RC4 (or whatever) and then back down to NULL that I
 EKR> think needs to be supported with measurements.

Come up with a SASL mechanism that allows recovering the plaintext
password on the server and the whole issue becomes moot. The idea of
downgrading encryption after authentication is a kludge to try and get
SASL PLAIN to serve that purpose; I don't particularly support the
idea, and I actually suspect that it won't work, and that unencrypted
SASL PLAIN or the historical AUTHINFO will be the de-facto standard
methods until a usable SASL method is defined.

This is a more general issue with SASL in that it does not support the
case where encryption of the session is not desirable, and
digest-based authentication methods are not available due to the
requirement for authentication to be handled by a third party.

-- 
Andrew.