Subject: [NNTP] draft-ietf-nntpext-authinfo-05 & draft-ietf-nntpext-tls-nntp-03

From: ken at oceana.com (Ken Murchison)
Date: Mon Oct 4 07:47:19 2004

Just sent these two drafts which hopefully include all issues/comments 
up to Clive's/Jeff's from this morning.  Changes from the previous 
versions are listed in Sections 0.

http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-05.txt
http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-03.txt

-- 
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: rra at stanford.edu (Russ Allbery)
Date: Mon Oct 4 12:55:51 2004

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-03.txt

These look good to me.  I'll give people a day to look them over (and for
them to get into the I-D repository) and then in the absence of objections
will advance them for IETF Last Call.

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

---

From: ken at oceana.com (Ken Murchison)
Date: Mon Oct 4 12:59:23 2004

> will advance them for IETF Last Call.

I just found a correction that needs to be made to the description of 
580 in Section 4 of NNTP-TLS (to coincide with 2.2.1), but this can 
probably wait until the 24 hour final review by the author(s).

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Oct 5 01:24:08 2004

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-03.txt

Just going through these now. Comments on the latter sent separately.

I've just realized there's a potential deadlock: what stops a server giving
483 to AUTHINFO and 480 to STARTTLS? Do we want to forbid the latter
(particularly since you can't use STARTTLS after authentication), or do we
want to leave this in the "too dumb to worry about" pile?

In authinfo-05, section 2.2, para 5 (of 7) I don't see the point of the
last sentence and in particular the SHOULD. See the similar comment on the
TLS document for details.
 
I still think the last paragraph of 2.2 does things wrong; I've given
my preference several times, so I won't repeat it again.

Apart from this, no comments. Good job.

-- 
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: ken at oceana.com (Ken Murchison)
Date: Tue Oct 5 06:43:13 2004

> want to leave this in the "too dumb to worry about" pile?

Not a bad idea, but I don't care either way.

> TLS document for details.

This dovetails with the fact that the capabilties might change after 
auth/tls and the client should check for this.  Russ, care to comment? 
I'm not married to this at this point, so I'll let the chair decide.

> my preference several times, so I won't repeat it again.

I apologize, I must have lost track of this in the threads or assumed 
that we had a consensus (all 4 of us :) otherwise.  Can you reiterate 
your argument and suggested text?

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Tue Oct 5 07:22:01 2004

> Not a bad idea, but I don't care either way.

I can reasonably see forbidding a 480 response to STARTTLS, I think.  
Thoughts on that?

If we don't like that idea, I'd say not to worry about this case any 
further.  I mean, it's not a protocol issue, for one thing.  And it's a 
fairly uncheckable/unenforceable specification.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: ken at oceana.com (Ken Murchison)
Date: Tue Oct 5 07:37:59 2004

> I can reasonably see forbidding a 480 response to STARTTLS, I think.  

I agree.  Since we don't allow STARTTLS after AUTHINFO, a 480 response 
to STARTTLS is nonsensical.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Oct 5 21:39:39 2004

Ken Murchison said:
[...]

I'm offline nearly all of today so can't do it now. I'll reply properly
to everything tomorrow.

---

From: rra at stanford.edu (Russ Allbery)
Date: Tue Oct 12 15:20:31 2004

>> last sentence and in particular the SHOULD. See the similar comment on
>> the TLS document for details.

> I'm not married to this at this point, so I'll let the chair decide.

As I understand it, any time that the capabilities change, the client
needs to query them again in order for the extensions mechanism to work
the way that it works for other protocols.  Therefore, the only time that
a client should continue without sending LIST EXTENSIONS is if they intend
to not use any extensions whatsoever, and if we're advertising the NNTP
protocol version in LIST EXTENSIONS as well, I think it would be better to
just have clients always send it.  So the SHOULD seems right to me.

---

From: rra at stanford.edu (Russ Allbery)
Date: Tue Oct 12 15:20:43 2004

> to STARTTLS is nonsensical.

Sounds right to me.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 03:24:03 2004

Russ Allbery said:
> to not use any extensions whatsoever,

Okay so far. But the following paragraph already explains that the contents
might change and why, and section 6 explains that you must discard any
knowledge of extensions when SASL comes into effect. If the client runs
into either of these situations, it will (re-)send LIST EXTENSIONS anyway.
If it doesn't, it has no need to and so the SHOULD is wrong.

I suggest dropping this sentence and merging the two paragraphs.

> and if we're advertising the NNTP
> just have clients always send it.

I don't follow the logic. The NNTP protocol version will not change just
because you've authenticated (I hope!). So asking for it again doesn't tell
you anything.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 03:34:03 2004

> I'm not married to this at this point, so I'll let the chair decide.

See my response to Russ.

> your argument and suggested text?

After a successful AUTHINFO command, the client MUST NOT issue another one.
Therefore the contents of the LIST EXTENSIONS response AUTHINFO line is
largely academic; its only use is as information as to what *was*
available. This has been accepted for SASL, but I believe it applies
equally well in every case if it applies at all.

So change the last paragraph of 2.2 to:

     After a successful authentication, the client MUST NOT issue another
     AUTHINFO command in the same session and a server MUST reject any
     further AUTHINFO commands with a 502 response.  For this reason,
     once authentication has happened the AUTHINFO line in the results of
     LIST EXTENSIONS is effectively irrelevant. Per [SASL], in order to
     allow the client to determine what options were available, the
     server MUST return the same arguments in this line as it would have
     done immediately before the successful authentication; inter alia
     this assists the detection of a possible active down-negotiation
     attack.

[Note that this swallows the first sentence of the paragraph two above; I'm
already arguing to lose the second sentence.]

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 03:36:31 2004

I wrote:
>> Therefore, the only time that

To make my position clearer, the SHOULD here says that a client is not
conforming if it doesn't send the LIST EXTENSIONS without a very good
reason. But if it doesn't need the results, there's no good reason, while
if it does then the SHOULD doesn't do anything anyway.

This doesn't seem to me to be an area that justifies the coercion of a
SHOULD.