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

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Oct 5 00:59:45 2004

Only two small points.

(1) Near the end of page 6 is the sentence "The client SHOULD send a LIST
EXTENSIONS command as the first command after a successful TLS negotiation",
with discussion of LIST EXTENSIONS in the next paragraph. I'm not sure of
the point of that sentence and in particular the SHOULD: the previous
sentence explains why you must forget any previous knowledge, and the next
paragraph says that the extension list could change.

In particular, if you want to do TLS to protect core commands, there's no
need to issue a LIST EXTENSIONS at all.

(2) I suggested a change to the last sentence of the first paragraph of
2.2.2.1. I've just realized I was slightly wrong - there are other commands
(notably LIST EXTENSIONS) for whice 483 is not permitted. So change:

    further NNTP commands from the client (other than a QUIT command)

to:

    further substantive NNTP commands from the client (note that the 483
    response is forbidden for some commands such as QUIT)

Alternatively, delete the "(other than a QUIT command)" comment entirely,
relying on [NNTP] to make the point.

You might also want to add a LIST EXTENSIONS to the last example to show
this.

-- 
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:46:08 2004

> paragraph says that the extension list could change.

I addressed this a little in your other post.

> need to issue a LIST EXTENSIONS at all.

Huh?  I don't follow.  After TLS, the available auth mechanisms may 
change, and a client really should check for this.

> (notably LIST EXTENSIONS) for whice 483 is not permitted. So change:

Good point.

> relying on [NNTP] to make the point.

Either way is fine with me.  Russ?

> You might also want to add a LIST EXTENSIONS to the last example to show

I'll look at this.

-- 
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: ken at oceana.com (Ken Murchison)
Date: Mon Oct 11 11:28:12 2004

> relying on [NNTP] to make the point.

How about "... further restricted NNTP commands from the client with a 
483 response code ...."

> You might also want to add a LIST EXTENSIONS to the last example to show

Actually, doesn't the use of GROUP local.public in the last example 
already illustrate this point?

---

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

> How about "... further restricted NNTP commands from the client with a

I like restricted better than substantive.  I think it's worthwhile making
sure that people know that there are exceptions like QUIT here in this
text.

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

---

From: ken at oceana.com (Ken Murchison)
Date: Tue Oct 12 16:34:57 2004

> sure that people know that there are exceptions like QUIT here in this

Suggested text?

---

From: rra at stanford.edu (Russ Allbery)
Date: Tue Oct 12 16:41:54 2004

>> I like restricted better than substantive.  I think it's worthwhile
>> making sure that people know that there are exceptions like QUIT here
>> in this text.

> Suggested text?

Your text looked fine to me; sorry, I wasn't clear.  I just like having a
word in there like "restricted" so that there's the implication that there
are still some other commands you can use.  I'm happy to defer exactly
what commands those are to the base document, which already covers that.

---

From: ken at oceana.com (Ken Murchison)
Date: Tue Oct 12 17:14:46 2004

> what commands those are to the base document, which already covers that.

Cool.

---

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

> sure that people know that there are exceptions like QUIT here in this

No objection from me.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 02:32:09 2004

> already illustrate this point?

That illustrates the 400. What I meant was, insert a LIST EXTENSIONS (which
should *succeed*) between the two GROUPs, showing that "483 to everything"
can't override the requirement for certain basic commands to work.

---

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

> change, and a client really should check for this.

If the only commands that you're going to use under TLS are ones in the
core specification, and nothing you're going to do requires separate
authorisation, then you don't need to do LIST EXTENSIONS.

It all depends on *why* you're doing TLS.

---

From: ken at oceana.com (Ken Murchison)
Date: Mon Oct 18 07:03:57 2004

> It all depends on *why* you're doing TLS.

True.  That's why its a SHOULD, not a MUST.

---

From: ken at oceana.com (Ken Murchison)
Date: Mon Oct 18 07:48:52 2004

> can't override the requirement for certain basic commands to work.

Ah, OK.  So is LIST EXTENSIONS the best way to illustrate this or should 
I insert a GROUP local.public (which I just noticed isn't included in 
that example)?  Or should I do both?  Three proposed examples are shown 
below.

[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation is attempted here]
[Following failed negotiation, traffic resumes without TLS]
[C] GROUP local.confidential
[S] 483 Encryption or stronger authentication required
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] STARTTLS
[S] OVER
[S] .
[C] GROUP local.private
[S] 400 Closing connection due to lack of security

[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation is attempted here]
[Following failed negotiation, traffic resumes without TLS]
[C] GROUP local.confidential
[S] 483 Encryption or stronger authentication required
[C] GROUPS local.public
[S] 211 321 4000 4321
[C] GROUP local.private
[S] 400 Closing connection due to lack of security

[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation is attempted here]
[Following failed negotiation, traffic resumes without TLS]
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] STARTTLS
[S] OVER
[S] .
[C] GROUP local.confidential
[S] 483 Encryption or stronger authentication required
[C] GROUPS local.public
[S] 211 321 4000 4321
[C] GROUP local.private
[S] 400 Closing connection due to lack of security