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

From: Ken Murchison <[email-masked]>
Date: Tue, 24 May 2005 14:14:19 -0400

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

---

From: EKR <[email-masked]>
Date: Tue, 24 May 2005 11:34:50 -0700

> document and most of the text you quote was taken directly from

Yeah, I suspect some revisions are in order.

> the list archives or renew this discussion.

Yes, I recall repeated vigorous assertions to this effect,
combined with fairly small amounts of data.  

Note: I'm not saying that the IETF should require confidentiality,
merely that it doesn't make sense for specs to go out of their
way to encourage people to turn it off without first estimating
the costs involved.

-Ekr

---

From: EKR <[email-masked]>
Date: Tue, 24 May 2005 11:35:23 -0700

Ken Murchison <[email-masked]> wrote:
> 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.

Thanks. 

Oh, one more note: you should consider a global replace of
"privacy" with "confidentiality"

-Ekr

---

From: Russ Allbery <[email-masked]>
Date: Tue, 24 May 2005 11:54:50 -0700

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

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.

Since there is no server-maintained persistant client state in NNTP, the
only risk of session hijacking is possibly being able to inject posts with
the authentication credentials of another user or being able to read
private hierarchies if there are any (on many news servers, there aren't
any that warrant any special precautions), neither of which are
particularly significant risks for most NNTP deployments.

Now there most certainly *are* NNTP deployments for which those are
significant risks.  Please don't read this as implying that NNTP never
cares.  It's just that the highest volume NNTP deployments tend to also be
the ones whose data warrants the least protection.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: EKR <[email-masked]>
Date: Tue, 24 May 2005 12:01:24 -0700

> I believe Andrew Gierth had concrete data in this area.

I'd be interested in seeing it. 

> encrypting the contents of public Usenet hierarchies.

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

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

-Ekr

---

From: Russ Allbery <[email-masked]>
Date: Tue, 24 May 2005 12:03:58 -0700

EKR <[email-masked]> writes:

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

Right, understood.  I do agree that that's a question to ponder.

> rehandshake. If you just wanted to do NULL all the time, I'd have no
> real argument with that. It's the desire to negotiate RC4 (or whatever)
> and then back down to NULL that I think needs to be supported with
> measurements.

That makes sense.  I don't think that down-negotiation is the approach
that anyone really wants; what we want is widespread deployment of a SASL
mechanism that encrypts the password but still sends it.  Unfortunately,
widespread deployment of any new SASL mechanism takes a long time (for
good reasons).  However, widespread deployment of TLS down-negotiation is
probably also not likely to happen quickly, so maybe that doesn't actually
help.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 24 May 2005 15:14:54 -0400

> probably also not likely to happen quickly, so maybe that doesn't actually

Unless someone vigorously objects, I think I'm going to remove any 
mention of down-negotiation from the draft.  I will be drafting an 
update to the expired PASSDSS SASL mech soon, which would hopefully be 
the best alternative to TLS+PLAIN.

---

From: Andrew Gierth <[email-masked]>
Date: Wed, 25 May 2005 11:52:05 +0100

>>>>> "EKR" == EKR  <[email-masked]> writes:

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

 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.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 25 May 2005 10:46:54 GMT

>the best alternative to TLS+PLAIN.

I think it should remain. Although the whole business of authenticating
and then down-negotiation is a kludge, I think it is a necessary kludge
for the time being, and therefore should be described correctly.

Of course, we all know that in practice people are going to continue to
send passwords in the clear, but you aren't supposed to say that while any
IETF people are listening :-) .

A news SASL mechanism is the ultimate and clean solution.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: EKR <[email-masked]>
Date: Wed, 25 May 2005 06:15:10 -0700

Andrew Gierth <[email-masked]> writes:

> not something that can simply be absorbed.  

Yeah, this falls more into the category of assertion than data. 

-Ekr

---

From: Russ Allbery <[email-masked]>
Date: Wed, 25 May 2005 09:19:29 -0700

> A news SASL mechanism is the ultimate and clean solution.

It seems unlikely to me that people are going to implement
down-negotiation faster than a new SASL mechanism, which makes it kind of
pointless to mention, doesn't it?

---

From: Ken Murchison <[email-masked]>
Date: Wed, 25 May 2005 16:27:52 -0400

> for the time being, and therefore should be described correctly.

I don't think it needs explicit mention in this document, since its 
something already allowed and discussed in RFC 2246.

I'd rather not document a temporary hack that implementors can figure 
out on their own anyways.  Looking back on it, I'm sorry I ever thought 
of and mentioned down-negotiation of the cipher.

---

From: Andrew Gierth <[email-masked]>
Date: Thu, 26 May 2005 06:21:16 +0100

>>>>> "EKR" == EKR  <[email-masked]> writes:

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

 EKR> Yeah, this falls more into the category of assertion than data. 

What sort of data would you like?

-- 
Andrew.

---

From: EKR <[email-masked]>
Date: Thu, 26 May 2005 09:10:43 -0700

> What sort of data would you like?

Throughput/load measurements on realistic traffic loads with
the SSL/TLS configurations in question. The standard reference
for Web traffic is:

C. Coarfa, P. Druschel, and D. Wallach. Performance Analysis of TLS
Web Servers. In Proceedings of NDSS '02,
2002. http://citeseer.ist.psu.edu/coarfa02performance.html

-Ekr

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 26 May 2005 08:04:17 -0400

> What sort of data would you like?

Does Andrew need to disclose CPU loads to make this point?

A rough estimate of throughput on a GigE is 100MB/second. At that
rate, with a 3.2 GHz processor clock, you get 32 clock cycles per byte
on average.  Those 32 clock cycles are precious:  to the
extent that you don't fill the I/O pipe, you need/waste hardware
resources (network and CPU.)

The real cost of encrypting is higher because the memory bus
runs at a slower speed.

---

From: EKR <[email-masked]>
Date: Thu, 26 May 2005 13:48:57 -0700

"Forrest J. Cavalier III" <[email-masked]> writes:
>>  EKR> Yeah, this falls more into the category of assertion than
>> data. What sort of data would you like?
>>
>

Well, some kind of measurement, yes. 

> The real cost of encrypting is higher because the memory bus

Yes, I'm familiar with all this, but what's relevant here is not
the absolute cost but the relative cost compared to other things that
are taking up CPU (Amdahl's law again). That's why you need
actual measurements.

-Ekr

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 26 May 2005 17:16:19 -0400

> are taking up CPU (Amdahl's law again). That's why you need

Are you saying that to be sure the bridge falls down, you must
build the bridge first?

I am not a SASL expert, but think of the issue in general...

It is my understanding that using symmetric ciphers on known and
public plaintext (e.g. Usenet messages) allows easy recovery of
the encryption keys.

There is no way that asymmetric ciphers are fast enough even on
CLIENTS, let alone servers, to use them for a general purpose
Usenet session.

One-time pads can help, but they are expensive CPU and storage
wise too.

Is anything left?

---

From: EKR <[email-masked]>
Date: Thu, 26 May 2005 14:27:48 -0700

> Are you saying that to be sure the bridge falls down, you must

No. I'm saying that you need to have some engineering model 
for what you're doing, and that involves having measurements
of the relative costs of various activities.

> public plaintext (e.g. Usenet messages) allows easy recovery of

Your understanding is incorrect. 

> CLIENTS, let alone servers, to use them for a general purpose

The way that modern comsec systems such as SSL/TLS work is that they
use an asymmetric algorithm for key exchange and then a symmetric
cipher for content encryption. As I indicated previously, there has
been quite a bit of performance work on this topic. See, for instance:

-Ekr

---

From: Ken Murchison <[email-masked]>
Date: Thu, 26 May 2005 23:15:39 -0400

At this point in the discussion, I figured it would be fair to let the 
WG know who "EKR" is for those of you that don't already know.  His name 
is Eric Rescorla and he is generally recognized as an expert in Internet 
Security, especially TLS.  If you choose to discuss any aspect of TLS 
(security aspects, performance metrics, etc), be sure to bring your "A" 
game, meaning know your stuff and bring facts to the table.  I 
personally feel that he has done us a great service by reviewing our 
document, and I don't want to waste his time if we can avoid it.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 May 2005 08:21:46 +0100

> public plaintext (e.g. Usenet messages) allows easy recovery of

This is a "known plaintext attack" or, for the POST command, a "chosen
plaintext attack".

These were a serious threat to WW2 cyphers (for example, they were at the
heart of breaking Enigma) but all modern cyphers, such as those used in
TLS, are designed to be immune to them.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Fri, 27 May 2005 07:04:18 -0400

On May 27, 2005, at 6:49 AM, Brian E Carpenter wrote:

> Sure, encryption and decryption on fat pipes is expensive.
> That's a well understood problem where I work. But is
> there anything specific to NNTP in this observation? Why would
> NNTP deserve a get out of jail card, and not other
> applications protocols?

Most web traffic goes unencrypted...why not require that HTTPS be used 
universally?

In that case, just like NNTP, there's a tremendous amount of data that 
is already public knowledge and encrypting it would provide minimal 
gain.  Sure, NNTP sometimes requires passwords to initiate a session -- 
but given the expense you describe above, commercial providers are wary 
of applying encryption to an entire multi-gigabyte datastream to 
protect the first few dozen bytes.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: EKR <[email-masked]>
Date: Fri, 27 May 2005 09:42:56 -0700

"Jeffrey M. Vinocur" <[email-masked]> writes:

> In that case, just like NNTP, there's a tremendous amount of data
> that is already public knowledge and encrypting it would provide
> minimal gain.  Sure, NNTP sometimes requires passwords to initiate a
> session --
> but given the expense you describe above, commercial providers are
> wary of applying encryption to an entire multi-gigabyte datastream to

Understood, but it's not just a matter of not applying encryption,
because you have to actually renegotiate. The question is whether it's
worth adding protocol and implementation complexity in order to avoid
incurring that cost.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 May 2005 12:49:31 +0200

Brian

---

From: Ade Lovett <[email-masked]>
Date: Fri, 27 May 2005 22:33:48 -0700

> NNTP deserve a get out of jail card, and not other

Compare the ratio of that part of an NNTP client/server exchange that  
"requires" encryption (essentially a secure version of AUTHINFO USER/ 
PASS for non-plaintext transfers), and that part that does not --  
downloading articles that are in the public domain.

If a particular connection wants to merely transmit authentication  
information securely, why should both sides then have to continue  
with such encryption for article data?  Once could argue that in the  
case where articles "need" to be transmitted securely, the nntps port  
is just sitting there, just as with http vs https.

"Secure" (or, rather, non-plaintext) authentication is something that  
comes up frequently in customer communication, both consumer and  
corporate outsourced.  Backend communication (once the NNTP server  
has received the information, and then processes it somewhere) is  
handled "securely" -- RADIUS and its shared secrets account for a  
considerable part of such behind the scenes verification, but having  
to maintain encryption overhead beyond authentication seems to be  
exceptional overkill.

-aDe