Subject: [NNTP] Fwd: GenART reviews of draft-ietf-nntpext-tls-nntp-07 and draft-ietf-nntpext-authinfo-09

From: Russ Allbery <[email-masked]>
Date: Fri, 22 Jul 2005 09:08:47 -0700

Some additional comments.

We're going to need new versions of both the authinfo and the tls drafts,
but probably only one more version of each.  I haven't checked the
grammatical corrections below in detail, but they look reasonable.  The
point about no encryption I'll follow up on (and cc the WG list).

From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2005 5:24 PM
To: [email-masked]
Cc: Hollenbeck, Scott; [email-masked]; [email-masked];
[email-masked]
Subject: GenART reviews of draft-ietf-nntpext-tls-nntp-07 and
draft-ietf-nntpext-authinfo-09

Background for those on the CC list, who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected as
the GenART member to review this document.  Below is my review, which
was written specifically with an eye to the GenART process, but since
I believe that it will be useful to have these comments more widely
distributed, others outside the GenART group are being copied.  Note
that since this review is in preparation for an IESG telechat,
authors/editors may want to wait until after you get post-telechat
feedback from your AD (who should be copied on this) on what the next
step is.  If you have followup information, please "reply to all."

++++++++++++++++

Drafts' names:  draft-ietf-nntpext-tls-nntp-07 and 
draft-ietf-nntpext-authinfo-09
Titles:  Using TLS with NNTP and NNTP Extension for Authentication and 
NNTP Extension for Authentication
Authors: J. Vinocur, K. Murchison, and C. Newman
Category: Standards track, Proposed standard

Review:  These drafts are ready for publication (I do have a request for 
clarification on the drafts)

Request for clarification
---------------------------
The applications of secure transport (from the authinfo I-D) are:   "to 
control resource consumption," "to allow abusers of the POST command to 
be identified," and "to restrict access to "local" groups."

The last one does require an encrypted channel, but I don't think the 
other two do.  An authenticated (integrity-protected) channel might be 
sufficient for some applications.  For applications which do not require 
confidentiality, why waste resources or put another way why slowdown 
downloads by making Encryption a MUST?  Thus, I think it would make 
sense for the drafts to specify an integrity only security layer as a 
MUST/SHOULD (e.g., TLS_RSA_WITH_NULL_SHA).

I am curious if the WG had this discussion.  If there was such a 
discussion and the drafts reflect the consensus, please ignore my 
comment above.  If not, perhaps it makes sense to specify such a mode 
for efficient operation.

<nit> RFC 2222 is in normative and informative references' sections in 
the authinfo I-D.  Is that intended? </nit>

<edit>Page 9, third paragraph from the bottom, last sentence of the 
-tls- I-D: "Furthermore, just because an NNTP server can authenticate 
..." is not clear, and may be incorrect: articles *from* the NNTP client 
... when the client *received* them.  Please correct/clarify that 
sentence. </edit>

<edit>  Please insert a "to" after the word "extension" in the abstract 
of -authinfo- ID.  </edit>

There may be a few other minor editorial things, but the RFC editor will 
catch them.

thanks and best regards,
Lakshminath

---

From: Russ Allbery <[email-masked]>
Date: Fri, 22 Jul 2005 09:14:51 -0700

> comment above.  If not, perhaps it makes sense to specify such a mode 

I'm not sure that I understand the clarification request.

TLS is only required for AUTHINFO USER/PASS or for SASL PLAIN, not for the
general SASL mechanism.  It's required there because the actual password
is being transmitted, and therefore encryption is required to protect it
from interception.  We did discuss the possibility of down-negotiation of
the confidentiality layer after authentication, but the working group (in
consultation with TLS experts) concluded that correct specification and
implementation of down-negotiation were too complex and unusual to be a
viable option.

When using a different SASL mechanism, confidentiality is not required.

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