Subject: Re: [NNTP] Extension snapshots 2

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 11:00:00 -0500

Russ Allbery wrote:

> Ken Murchison <[email-masked]> writes:
> 
> 
>>http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-06pre2.txt
> 
> 
> I believe we should not allow AUTHINFO both before and after MODE READER.
> In other words, if you're going to send MODE READER, do it first before
> you do anything else.  You can either not send it at all or send it as the
> first thing you do, but you can't authenticate, use some transit commands,
> and then send MODE READER to switch over to the reader server.

So, do you want to prohibit this unilaterally, e.g.:

"Servers MUST NOT allow the use of MODE READER after successful 
authentication."

Or only prohibit it on mode-switching servers, e.g.:

"Mode-switching servers MUST NOT allow the use of MODE READER after 
successful authentication."

I'm open to different/additional text if you have any ideas.  Of course, 
all of this is moot if we decide to get rid of MODE READER.  Where do we 
stand on this?

> It's not clear to me what the utility of noting whether an extension is a
> transit, reader, or general command, given that they have their own
> capabilities.  Could someone remind me why that's needed?

It probably isn't needed, and I was about to remove it, but I noticed 
that the "standard" extensions in section 8 of base-pre5 note that they 
are all reader commands, as do the IANA registrations in Appendix C.

Can you make a formal decision on whether we want this or not, so we can 
have the base doc and extension docs do the same thing?

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 4 Jan 2005 16:06:20 +0000

> have the base doc and extension docs do the same thing?

I'm still thinking through the rewrite of section 8 of the core document,
but I strongly suspect that this concept will disappear as a result.

-- 
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: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 09:46:39 -0800

> successful authentication."

Can we turn this around and say instead that the client MUST NOT send it
after successful authentication?  Then there's no pressing need to say
what the server has to do.

> all of this is moot if we decide to get rid of MODE READER.  Where do we

Well, I've said where I stand on it, and Andrew (as another implementor
who's written news software other than INN) feels (correct me if I'm
wrong) that it's necessary to keep.  If someone comes up with a neat way
of letting INN not need it, that's great by me, but I don't have the time
to work on that and my intuition tells me it would be tricky.

> have the base doc and extension docs do the same thing?

Sounds like Clive is on the trail of this already as part of figuring out
what to do with transit vs. reader servers.  I don't think it's necessary
to note transit vs. reader on commands that have their own capability
strings.

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 13:09:21 -0500

> what the server has to do.

But only the server knows if its truely mode-switching (in lieu of a 
MODE READER capability -- which only VERSION 2 capable clients will know 
about) and the client may always send MODE READER just to cover its ass.

I'm worried about breaking existing clients (e.g. Pine) which have found 
a sequence of commands which work on almost all servers (mode-switching 
INN being the notable exception).

And if we do make a note regarding the use of MODE READER after 
authentication, do we do so only in the context of mode-switching, or 
unilaterally?

Ideally, a mode-switching server would discontinue advertising the MODE 
READER capability after TLS and/or authentication.

And perhaps we dance around this issue a little and say something like 
this in the base doc:

"If a client intends to use the MODE READER command, it SHOULD issue 
this command before any security or privacy commands are issued."

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 10:23:45 -0800

> about) and the client may always send MODE READER just to cover its ass.

There's no point in sending MODE READER after authentication, though; it
won't do anything useful.  I think we need to make that clear to future
implementors.

> INN being the notable exception).

Well, what Pine is doing is broken.  It doesn't actually accomplish what
Pine was attempting to accomplish.  The reason why Mark was able to think
that it was a good idea is because there wasn't any standard to say "don't
do that."  So I think we should be very clear about this.

Pine is not going to comply with any standard that fits how MODE READER
works with existing servers, since what Pine does doesn't actually work.

> authentication, do we do so only in the context of mode-switching, or

MODE READER has no purpose except with a mode-switching server or to cover
one's ass just in case one is talking to a mode-switching server, so I
think that we should describe how to send it unilaterally.

> READER capability after TLS and/or authentication.

Oh, definitely.  Any client that can watch the capabilities won't have a
problem with this.

> this command before any security or privacy commands are issued."

I don't see any reason to leave it that mild.  I would say:

    If a client intends to use the MODE READER command, it SHOULD issue it
    before issuing any commands other than CAPABILITIES and MUST issue it
    before any security or privacy commands are issued.

The client knows whether it wants to be a reader or a peer.  The only
thing it needs to do before issuing MODE READER is to check whether it's
needed.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 13:40:29 -0500

> think that we should describe how to send it unilaterally.

OK, I'm fine with this.  My question is what text goes where?  See below.

> Oh, definitely.  Any client that can watch the capabilities won't have a

OK, so should I state in AUTHINFO/STARTTLS that the MODE_READER 
capability (is this what we're calling it?) SHOULD (MUST?) NOT be 
advertised after successful authentication/TLS negotiation?

As an alternative (or in addition to the above) should I state in 
AUTHINFO/STARTTLS that client MUST NOT issue MODE READER after 
successful authentication/TLS negotiation?

> thing it needs to do before issuing MODE READER is to check whether it's

Works for me.

Since the above text would go into the base doc and the issue of 
capabilities being added/removed as a result of other commands is also 
addressed in the base doc, I'm wondering what kind of text you want to 
see in the AUTHINFO and STARTTLS docs.  It seems to me that most, if not 
all, of the MODE READER issue can be addressed in the base doc, thus 
eliminating duplicate text in AUTHINFO, STARTTLS and any other 
security/privacy extensions down the road.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 10:47:01 -0800

> advertised after successful authentication/TLS negotiation?

MUST NOT.  Yes.

> successful authentication/TLS negotiation?

I think we can say both -- the latter is still useful when dealing with
servers that don't have capabilities.

> security/privacy extensions down the road.

Yeah, that would work.  I don't know if there's merit in just restating
the point briefly in a sentence or two, just to make sure that
implementors don't miss it by not reading the generic section of the base
document.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 14:34:11 -0500

> implementors don't miss it by not reading the generic section of the base

OK, here's the current AUTHINFO passages w.r.t. MODE READER.  Comments? 
  I'll make similar changes to STARTTLS once we can agree on some text.

Section 2.1 ("Advertising the AUTHINFO Extension")

"A server MUST implement at least one of the AUTHINFO USER or AUTHINFO
SASL commands in order to advertise the AUTHINFO capability in the
response to the CAPABILITIES command.  However, this capability is not
advertised after successful authentication (see section 2.2).  This
capability MAY be advertised both before and after any use of MODE
READER, with the same semantics."

Section 2.2 ("Authenticating with the AUTHINFO Extension")

"After a successful authentication, the client MUST NOT issue another
AUTHINFO command or a MODE READER command in the same session.  A
server MUST NOT return the AUTHINFO or MODE_READER capabilities in
response to a CAPABILITIES command and a server MUST reject any
subsequent AUTHINFO or MODE READER commands with a 502 response.  In
agreement with [SASL], if a security layer is established as part of
the authentication, the server MUST continue to advertise the SASL
capability in response to a CAPABILITIES command with the same list of
SASL mechanisms as before authentication (thereby enabling the client
to detect a possible active down-negotiation attack)."

Section 2.4 ("AUTHINFO SASL Command")

"When a security layer takes effect, the NNTP protocol is reset to the
state immediately after the most recent MODE READER response (see 5.3
or [NNTP]) or initial greeting response (see 5.1 of [NNTP]) has been
sent.  The server MUST discard any knowledge obtained from the client,
such as the current newsgroup and article number, that was not
obtained from the SASL negotiation itself.  Likewise, the client
SHOULD discard and MUST NOT rely on any knowledge obtained from the
server, such as the capability list, that was not obtained from the
SASL negotiation itself.  (Note that a client MAY compare the
advertised SASL mechanisms before and after authentication in order to
detect an active down-negotiation attack.)"

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 14:41:29 -0500

> to detect a possible active down-negotiation attack)."

As an alternative to the above, I could leave the paragraph as-is (no 
mention of MODE READER) and augment the following paragraph to read:

"The capability list returned in response to a CAPABILITIES command
received after authentication MAY be different that the list returned
before authentication.  For example an NNTP server may not want to
advertise support for a specific extension unless a client has been
authenticated.  Likewise, mode-switching servers are not permitted to 
advertise the MODE_READER capability after authentication."

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 11:42:53 -0800

> READER, with the same semantics."

I don't think this requires any changes.

> AUTHINFO command or a MODE READER command in the same session.  A server
> MUST NOT return the AUTHINFO or MODE_READER capabilities in response to
> a CAPABILITIES command and a server MUST reject any subsequent AUTHINFO
> or MODE READER commands with a 502 response.  In agreement with [SASL],
> if a security layer is established as part of the authentication, the
> server MUST continue to advertise the SASL capability in response to a
> CAPABILITIES command with the same list of SASL mechanisms as before
> authentication (thereby enabling the client to detect a possible active
> down-negotiation attack)."

I would leave MODE READER out of the server MUST reject part, to leave the
door open for non-mode-switching servers that want to just always return
200 to MODE READER all the time.  I guess that's what you were driving at
with your original question.  I do agree that the MODE_READER capability
MUST NOT be advertised (since that invites clients to use it), and the
client language looks right to me.

> state immediately after the most recent MODE READER response (see 5.3 or
> [NNTP]) or initial greeting response (see 5.1 of [NNTP]) has been sent.

This sounds a little odd to me, since it sort of implies that MODE READER
creates a state "checkpoint" that you then revert back to.  It's partly
taken care of by the next sentence:

> The server MUST discard any knowledge obtained from the client, such as
> the current newsgroup and article number, that was not obtained from the
> SASL negotiation itself.

but it still leaves me feeling a bit uncomfortable.

I wonder if we can avoid that by being more explicit, saying something
like:

   When a security layer takes effect, the NNTP protocol is reset to the
   state immediately after the initial greeting response (see 5.1 of
   [NNTP]) has been sent, with the exception that if a MODE READER command
   has been issued, the effects of it (if any) are not reversed.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 14:59:01 -0500

> client language looks right to me.

OK, given that all we care about is the advertising of the capability, 
can we just rely on the base doc and remind people with my alternative text:

"The capability list returned in response to a CAPABILITIES command
received after authentication MAY be different that the list returned
before authentication.  For example an NNTP server may not want to
advertise support for a specific extension unless a client has been
authenticated.  Likewise, servers are not permitted to advertise the 
MODE_READER capability after authentication (see X.X of [NNTP])."

>    has been issued, the effects of it (if any) are not reversed.

This works for me.  I might replace "reversed" with "reset" or "undone".

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 12:50:13 -0800

> MODE_READER capability after authentication (see X.X of [NNTP])."

The only reason why I'm leery of that approach is that sending MODE READER
after authentication could potentially break something (if you
authenticate to the transit server and then switch to the reader server,
for instance).  Of course, a client shouldn't send MODE READER unless
MODE_READER is advertised as a capability -- maybe that's all we need.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 16:25:09 -0500

> MODE_READER is advertised as a capability -- maybe that's all we need.

OK, how about this?  I think I state everything that you want as well as 
refer to the base doc.

"After a successful authentication, the client MUST NOT issue another
AUTHINFO command in the same session.  A server MUST NOT return the
AUTHINFO capability in response to a CAPABILITIES command and a server
MUST reject any subsequent AUTHINFO commands with a 502 response.
Additionally, per section X.X of [NNTP], the client MUST NOT issue a
MODE READER command after authentication and a server MUST NOT
advertise the MODE_READER capability.

In agreement with [SASL], if a security layer is established as part
of the authentication, the server MUST continue to advertise the SASL
capability in response to a CAPABILITIES command with the same list of
SASL mechanisms as before authentication (thereby enabling the client
to detect a possible active down-negotiation attack).

The capability list returned in response to a CAPABILITIES command
received after authentication MAY be different that the list returned
before authentication.  For example, an NNTP server may not want to
advertise support for a specific extension unless a client has been
authenticated."

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 13:25:07 -0800

> MODE READER command after authentication and a server MUST NOT advertise
> the MODE_READER capability.

> In agreement with [SASL], if a security layer is established as part of
> SASL mechanisms as before authentication (thereby enabling the client to
> detect a possible active down-negotiation attack).

> advertise support for a specific extension unless a client has been

Looks great to me.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 6 Jan 2005 16:26:41 +0000

>     before any security or privacy commands are issued.

What I've put in snapshot 6 is:

   A client MAY use the CAPABILITIES command to determine whether it
   needs to issue a MODE READER command and SHOULD NOT do so if it is
   unnecessary.  If the server does not support CAPABILITIES (and
   therefore does not conform to this specification), the client MAY use
   the following heuristic:
   o  if the client wishes to use the IHAVE command, it SHOULD NOT use
      the MODE READER command or any command that is not marked as 
      mandatory in this specification;
   o  otherwise the client SHOULD use the MODE READER command
      immediately after the initial connection, and then SHOULD NOT use
      the IHAVE command.

and, elsewhere:

   The client MUST NOT send this command
   after any other command except CAPABILITIES (in particular, it MUST
   NOT send this command twice in a session); if it does so, the server
   MAY violate this specification even if it returns a successful
   response (for example, the server MAY forget the currently selected
   newsgroup or change its privacy or authentication status).

How's that?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 6 Jan 2005 16:53:26 +0000

Russ Allbery said:
> I do agree that the MODE_READER capability
> MUST NOT be advertised (since that invites clients to use it),

Oh hell, I overlooked that. I need to change some of the pre-6 wording.

3.4.2 now says:

   A mode-switching server has three modes:
   o Initial mode, after the initial connection:
      * it MUST advertise the MODE-READER capability;
      * it MUST advertise the IHAVE capability;
      * it MUST advertise the READER capability with the -MODE-READER
        modifier;
      * it MAY advertise other capabilities with the -MODE-READER modifier;
        if these have other modifiers as well, -MODE-READER should be first.
   o Reading mode, after a successful MODE READER command:
      * it MUST advertise the READER capability;
      * it MAY advertise the IHAVE capability;
      * it SHOULD advertise the MODE-READER capability with the -- modifier;
      * it SHOULD advertise, without the -MODE-READER modifier, any other
        capabilities it was advertising with that modifier.
   o Transit mode, after any command except CAPABILITIES or a successful
     MODE READER command:  
      * it MUST advertise the IHAVE capability;
      * it MAY advertise the MODE-READER capability; there are
        circumstances where it SHOULD NOT do so.

and MODE READER now has added:

    The server MAY cease to advertise the MODE-READER capability once
    the client is no longer permitted to use the command, and SHOULD do
    so if the command would have unexpected effects.

I can easily be convinced to change the last two SHOULDs to MUST.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 06 Jan 2005 12:04:13 -0500

> Oh hell, I overlooked that. I need to change some of the pre-6 wording.

I have other pre-6 comments that I'm accumulating, but since you've 
singled out this text, I'll comment here.

>       * it MUST advertise the READER capability with the -MODE-READER

Since you state elsewhere that capability modifiers aren't required to 
be used by a server, I object to the MUST above.  Either change the MUST 
to SHOULD, or rewrite it to something like:

"* the READER capability MUST NOT be advertised unless prefixed with the 
-MODE-READER modifier;"

>       * it SHOULD advertise the MODE-READER capability with the -- modifier;

Same objection as above.  Perhaps:

"* it SHOULD NOT advertise the MODE-READER capability unless prefixed 
with the -- modifier;"

> I can easily be convinced to change the last two SHOULDs to MUST.

I'd in favor of MUST unless there is good reason not to.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 06 Jan 2005 15:02:04 -0500

>    newsgroup or change its privacy or authentication status).

I thought the sentence that Russ came up with pretty much says all that 
needs to be said.  I'm not sure what else your more verbose text adds to 
this, unless I'm missing something.  In fact, it seems somewhat 
confusing (I had to read it a few times).

Don't we also want text somewhere that states that "the MODE-READER 
capability MUST NOT be advertised after any security or privacy commands 
have completed successfully"?

---

From: Russ Allbery <[email-masked]>
Date: Thu, 06 Jan 2005 15:25:51 -0800

>>       mandatory in this specification;

I'm not sure we need the bit after the "or"; I don't think that really
provides anything useful at this point.  It's not like the world ends if
they try it and the command fails, since we're already into guesswork
territory given that the server doesn't support CAPABILITIES.

>>       immediately after the initial connection, and then SHOULD NOT use

Likewise here, I would drop everything after the comma.

>>    The client MUST NOT send this command after any other command except
>>    CAPABILITIES (in particular, it MUST NOT send this command twice in
>>    a session); if it does so, the server MAY violate this specification
>>    even if it returns a successful response (for example, the server
>>    MAY forget the currently selected newsgroup or change its privacy or
>>    authentication status).

>> How's that?

I would replace this whole paragraph with my paragraph from before:

I don't think we need to allow for the server doing strange things in
response to a second MODE READER command.

> have completed successfully"?

Yes, I think so.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 06 Jan 2005 15:30:15 -0800

> Since you state elsewhere that capability modifiers aren't required to be
> used by a server, I object to the MUST above.  Either change the MUST to
> SHOULD, or rewrite it to something like:

> "* the READER capability MUST NOT be advertised unless prefixed with the

Agreed.

> I'd in favor of MUST unless there is good reason not to.

I would just say that the server MUST NOT advertise the MODE-READER
capability after MODE READER has been used *or* when the server is in
reader mode already.  Remember, a client that doesn't support modifiers
can be expected to key off the presence of that capability to decide
whether to issue the command, and a naive implementation could loop if the
capability isn't dropped.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 7 Jan 2005 15:22:23 +0000

> "* the READER capability MUST NOT be advertised unless prefixed with the 

Good point.

> I'd in favor of MUST unless there is good reason not to.

Russ has pointed out a good reason: a client could say "if CAPABILITIES
returns MODE-READER, I'll invoke MODE-READER" and loop.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 7 Jan 2005 15:39:28 +0000

> territory given that the server doesn't support CAPABILITIES.

True. I was trying to write text that says "beware, the server might be
mode-switching and so won't support both IHAVE and GROUP etc. at the
same time".

How about this?

    o  if the client wishes to use the IHAVE command, it SHOULD NOT use
       the MODE READER command, but should be prepared for some
       commands to be unavailable;

or "some READER commands".

> Likewise here, I would drop everything after the comma.

Okay.

>     before any security or privacy commands are issued.

I was going to object to calling out security or privacy specially, but
I've just remembered we do that elsewhere.

> response to a second MODE READER command.

Remember that "strange things" includes forgetting the currently selected
group. Put another way, does MODE READER reset the internal state or not?
We never did resolve that, and that's what I'm trying to avoid having to
do.

Editorially, I don't like "intends to use" as a way of describing protocol
restrictions. All existing uses of the term are usage like "The IHAVE
command is intended for transmitting conforming articles between a system
of NNTP servers".

>> have completed successfully"?

Actually, given this whole thing is aimed at solving one very restricted
problem, how about being prescriptive:

    The client MUST NOT send this command, and the server MUST NOT
    advertise the MODE-READER capability, after any other command except
    CAPABILITIES has been used in the session.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 7 Jan 2005 15:45:20 +0000

Ken Murchison said:
> In

Can we drop the condition, and just have the SASL capability be advertised
throughout the session?

If it's a useful technique at all (I remain skeptical) then leave the
possibility open no matter who's providing the security.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 07 Jan 2005 11:25:18 -0500

> possibility open no matter who's providing the security.

Its *really* only useful iff a security layer has been negotiated. 
Otherwise an attacker can falsify the list of SASL mechanisms both 
before and after AUTHINFO SASL without the client knowing it.

But if Russ feels we should leave it open and always advertise SASL, 
then I won't argue.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 7 Jan 2005 15:01:43 GMT

>      mandatory in this specification;

No, that is not right. We say somewhere that you MAY provide IHAVE when in
READER mode (though its detailed bahaviour may be slightly different).

>      immediately after the initial connection, and then SHOULD NOT use

Ditto.

OK, in actual practice, I currently use IHAVE in READER mode, but only
because I am not authorized for TRANSIT mode (i.e. I start off in NNRPD).
But I don't see why it should not be possible to get into that same state
(even though one might have the necessary authority) by issuing MODE
READER.

-- 
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: Russ Allbery <[email-masked]>
Date: Fri, 07 Jan 2005 10:07:19 -0800

>> provides anything useful at this point.  It's not like the world ends
>> if they try it and the command fails, since we're already into
>> guesswork territory given that the server doesn't support CAPABILITIES.

> mode-switching and so won't support both IHAVE and GROUP etc. at the

Except that some of them do.  *sigh*.

> or "some READER commands".

Yeah, this is what I was worrying about in the other message.

I think we should invert the sense of this, because that's what actually
matches what people do in practice:

 o if the client wishes to use any reader commands, it SHOULD use the
   MODE READER command immediately after the initial connection;

 o otherwise, it SHOULD NOT use the MODE READER command, but should be
   prepared for some commands to be unavailable.

That avoids the issue that some reader servers do also provide IHAVE.

> Remember that "strange things" includes forgetting the currently
> selected group. Put another way, does MODE READER reset the internal
> state or not?

It does not in INN.

> We never did resolve that, and that's what I'm trying to avoid having to

That's probably a good thing, because I can't be sure how other servers
might implement it.  However, I think I'd rather tell the client not to
send it twice than talk about what the server might do if it does.  I am
convinced by the above that it's probably worth telling the client not to
send it twice.

>     CAPABILITIES has been used in the session.

Hm.  It's more complexity for the server to keep an internal state flag
and know if other commands have been used in the session.  That part of
this is kind of ugly; if it weren't for that, I'd like the idea.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 07 Jan 2005 10:08:37 -0800

>> Can we drop the condition, and just have the SASL capability be
>> advertised throughout the session?  If it's a useful technique at all
>> (I remain skeptical) then leave the possibility open no matter who's
>> providing the security.

> Its *really* only useful iff a security layer has been
> negotiated. Otherwise an attacker can falsify the list of SASL
> mechanisms both before and after AUTHINFO SASL without the client
> knowing it.

> But if Russ feels we should leave it open and always advertise SASL, then
> I won't argue.

Isn't the key bit in the above the "same list of SASL mechanisms" part?  I
don't see any way of keeping that bit in without saying something like the
above, since there are other circumstances besides negotiating a security
layer via SASL where the advertised list *can* change.  (As a result of
STARTTLS, for instance.)

---

From: Russ Allbery <[email-masked]>
Date: Fri, 07 Jan 2005 10:10:50 -0800

> this is kind of ugly; if it weren't for that, I'd like the idea.

And, actually, even worse than that, this says that the output of
CAPABILITIES may change in circumstances other than the places we've
documented that explicitly (AUTHINFO, STARTTLS, and MODE READER).  I don't
think that's a good idea; the CAPABILITIES output shouldn't vary except as
a result of specific commands that perform major state changes and are
documented as possibly changing the server capabilities.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 07 Jan 2005 13:27:09 -0500

> documented as possibly changing the server capabilities.

What if we said something like this instead:

The client MUST NOT send this command, and the server MUST NOT
advertise the MODE-READER capability, if the server is already in the 
"reader" state (designated by the advertisement of the READER 
capability), or if a privacy or security command has been issued 
successfully.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 07 Jan 2005 11:15:54 -0800

> "reader" state (designated by the advertisement of the READER capability),
> or if a privacy or security command has been issued successfully.

I got lost in the middle of that sentence.  Maybe this is a bit clearer?

    The client SHOULD NOT issue MODE READER after issuing any commands
    other than CAPABILITIES and MUST NOT issue it more than once or after
    any security or privacy commands are issued.  The server MUST NOT
    advertise the MODE-READER capabiliity after a successful MODE READER,
    privacy, or security command.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 07 Jan 2005 14:32:00 -0500

Works for me.

---

From: [email-masked] (Peter Robinson)
Date: Sun, 9 Jan 2005 21:59:38 +0000

> Can we drop the condition, and just have the SASL capability be advertised

Surely this is exactly the kind of situation that the -- capability
modifier is useful for.

>From pre-6 3.3.3 Capability modifiers:

| --
|     the capability cannot be re-enabled in this session

Peter

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 10 Jan 2005 13:02:52 GMT

>or "some READER commands".

No, that is still wrong because using IHAVE is a respectable thing to do
when in "reader" mode (even if you got into that mode by issuing MODE
READER) - at least for those servers that allow it.

But I think Russ's latest suggested wording fixes it.

-

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 11 Jan 2005 08:37:05 +0000

> That avoids the issue that some reader servers do also provide IHAVE.

But it loses the warning that some of them don't!

How about this:

   o if the client wishes to use any "reader" commands, it SHOULD use
     the MODE READER command immediately after the initial connection;

   o otherwise it SHOULD NOT use the MODE READER command.

   In each case it should be prepared for some commands to be
   unavailable that would have been available if it had made the other
   choice.

Is that an acceptable compromise between the various messages we're trying
to get across?

> convinced by the above that it's probably worth telling the client not to

Okay. So we're in general agreement on that. I'll follow up the details in
another message.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 11 Jan 2005 09:33:37 +0000

> layer via SASL where the advertised list *can* change.  (As a result of

True. All I'm asking is that the SASL capability remain advertised.

How about:

    The server MUST advertise the SASL capability throughout the session,
    even if no longer advertising the AUTHINFO capability. It MUST NOT
    change the list of SASL mechanisms as an effect of the AUTHINFO
    command, even if this establishs a security layer. (As described by
    [SASL], this then enables the client to to detect a possible active
    down-negotiation attack.) It MAY change the list as an effect of
    other commands or extensions (e.g. [NNTP-TLS]).

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 11 Jan 2005 10:14:29 +0000

>     privacy, or security command.

Um, can I take a step back and try to look at the principles that we're
trying to address?

(1) When should the client issue MODE READER?
  (a) If the server doesn't do CAPABILITIES, then it has to guess. We're
      doing that wording in a separate sub-thread.
  (b) We don't want the client to issue MODE READER after any kind of
      server state change, because it means we have to either define, or
      explicitly leave open, what happens to the server state.

Therefore the easiest way to address this is:

    The client MUST NOT issue MODE READER after any other command except
    CAPABILITIES has been used in the session.

Note: by making it a MUST NOT, we don't have to worry about violations of
this rule. If we make it a SHOULD NOT, that suggests there are situations
where it is sensible to violate it, and so client authors are entitled to
know what the implications are so that they can decide if they are an
exceptional case. That opens the whole internal state can of worms.
Therefore it seems best to make it a MUST NOT.

(2) When should the server advertise MODE-READER? Well, advertising it
suggests to the client that MODE READER is something to think about doing.
So we get:
  (a) Not if the server isn't mode-switching.
  (b) Not if it opens the internal state can of worms.
  (c) Not if the client MUST NOT send it.

We can address (a) by:

    The server MUST NOT advertise the MODE-READER capability if it is not
    mode-switching.

We can address (b) by:

    The server MUST NOT advertise the MODE READER command after a
    successful MODE READER, authentication, or privacy command {or
    after any command that changes the server state}.

(the words in braces are an additional suggestion).

(c) is harder, however. It would be easy to address by:

    The server MUST NOT advertise the MODE READER command after the
    client has issued any command except CAPABILITIES.

This subsumes (b), but it hits Russ's objection about secretive state
changes in the server. If we don't do it, however, then we could find
MODE-READER being advertised when the client MUST NOT use it. We could fix
this thus:

    The client MUST NOT issue MODE READER after any other command except
    CAPABILITIES has been used in the session, even if the server is
    still advertising the MODE-READER capability.

That feels like the wrong thing to do, because the whole point of
capabilities is to tell clients what they can do.

I must say that I'm not convinced by Russ's argument. Setting an internal
flag in the server might be a minor pain but is it that bad? As for
>>> the CAPABILITIES output shouldn't vary except as
>>> a result of specific commands that perform major state changes
I think that's too strong a statement. We've told the client that issuing
any other command makes MODE READER illegal, so this *is* an explicit state
change.

For that matter, the traditional implementation of LIST XXX is to look for
the file XXX and, if found, dump it at the client. If a server operator
adds a new file, should the LIST capability change or not? Surely it
should?

So, after merging sentences, this leaves me with two alternative wordings
to offer:

(A) If you accept my arguments:

    The client MUST NOT issue MODE READER after any other command except
    CAPABILITIES has been used in the session.

    The server MUST NOT advertise the MODE-READER capability unless it is
    mode-switching and the client has not used any command in the session
    except CAPABILITIES.

(B) If you don't accept them, but continue to support Russ's view:

    The client MUST NOT issue MODE READER after any other command except
    CAPABILITIES has been used in the session, even if the server is
    still advertising the MODE-READER capability.

    The server MUST NOT advertise the MODE-READER capability if it is not
    mode-switching, and MUST NOT advertise it after any command that
    changes the server state, including but not limited to a successful
    MODE READER, authentication, or privacy command.

Now what?

[In both cases, there is some additional wordsmithing like "except with the
-- modifier" that I'm leaving out to make this discussion clear.]

---

From: Russ Allbery <[email-masked]>
Date: Tue, 11 Jan 2005 15:22:15 -0800

>     other commands or extensions (e.g. [NNTP-TLS]).

This is fine with me.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 11 Jan 2005 15:28:14 -0800

>>     other than CAPABILITIES and MUST NOT issue it more than once or
>>     after any security or privacy commands are issued.  The server MUST
>>     NOT advertise the MODE-READER capabiliity after a successful MODE
>>     READER, privacy, or security command.

>     CAPABILITIES has been used in the session.

Yes, but I really strongly dislike changing CAPABILITIES in response to
anything other than AUTHINFO, STARTTLS, or MODE READER among our current
commands.  The capability list is something that we're telling the client
to rely on, remember, and use to determine what it should do, and we're
telling them explicitly to refresh it after they do something that might
change it.  I think those are the correct and valuable things to say, and
I don't want to introduce anything that weakens it.

In practice, note, sending MODE READER after doing a few other things will
work and will not pose any interoperability issues; the interoperability
issues only arise if MODE READER is sent after AUTHINFO or STARTTLS.

> Note: by making it a MUST NOT, we don't have to worry about violations
> of this rule. If we make it a SHOULD NOT, that suggests there are
> situations where it is sensible to violate it, and so client authors are
> entitled to know what the implications are so that they can decide if
> they are an exceptional case. That opens the whole internal state can of
> worms.

I don't think the worms are particularly significant.  I really do think
that my above text covers the situation and doesn't require any additional
worries about states.

Could you explain more what you're concerned about?

> MODE-READER being advertised when the client MUST NOT use it. We could
> fix this thus:

> capabilities is to tell clients what they can do.

Not to mention that we can't really justify a MUST NOT here on
interoperability grounds, since that action is actually quite well-defined
and doesn't pose interoperability problems.

> For that matter, the traditional implementation of LIST XXX is to look
> for the file XXX and, if found, dump it at the client. If a server
> operator adds a new file, should the LIST capability change or not? 
> Surely it should?

I wouldn't implement it that way, no.

> So, after merging sentences, this leaves me with two alternative
> wordings to offer:

I prefer my wording above to either of these.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 11 Jan 2005 15:22:00 -0800

> Is that an acceptable compromise between the various messages we're
> trying to get across?

Sounds good to me.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 12 Jan 2005 11:12:47 GMT

>issues only arise if MODE READER is sent after AUTHINFO or STARTTLS.

Indeed. Many servers implement commands like HELP and SLAVE, and I am sure
no harm would arise if these were sent before MODE READER. Even LIST
ACTIVE would not break anything. Essentially, what you mean is that state
changing commands MUST NOT be sent first.

     The client MUST NOT issue MODE READER after any other command except
     those which make no change to the state, such as CAPABILITIES,
     has been used in the session.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 12 Jan 2005 10:49:04 -0500

>>    other commands or extensions (e.g. [NNTP-TLS]).

I like Clive's wording, but it didn't seem to fit seemlessly with the 
current text.  Here's what I have now, which is a merging and slight 
modification of two adjacent paragraphs in pre3:

"In agreement with [SASL], the server MUST continue to advertise the SASL
capability in response to a CAPABILITIES command with the same list of
SASL mechanisms as before authentication (thereby enabling the client
to detect a possible active down-negotiation attack).  Other
capabilities returned in response to a CAPABILITIES command received
after authentication MAY be different than those returned before
authentication.  For example, an NNTP server may not want to advertise
support for a specific extension unless a client has been
authenticated."

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 12 Jan 2005 15:52:05 +0000

Works for me.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 17 Jan 2005 11:28:16 +0000

>>>     READER, privacy, or security command.

[Charles notes that "other than CAPABILITIES" would be better worded as
"that change the state of the server".]

>>       explicitly leave open, what happens to the server state.

This is still a major objective, as I see it.

> I don't want to introduce anything that weakens it.

I think you're being over-hopeful. On the contrary, what we say is:

    The response generated by this command MAY change during a session
    because of other state information (which in turn may be changed by
    the effects of other commands). An NNTP client is only able to get
    the current and correct information concerning available capabilities
    at any point during a session by issuing a CAPABILITIES command at
    that point of that session and processing the response.

That wording (which came from LIST EXTENSIONS, IIRC) certainly implies that
the available capabilities can change for reasons other than specific
commands.

In particular, I can imagine a server architecture where the administrator
can load and unload modules dynamically.

> issues only arise if MODE READER is sent after AUTHINFO or STARTTLS.

Or GROUP or LISTGROUP. Or anything else which sets state (admittedly, the
current selected group is the only state which comes to mind).

> I don't think the worms are particularly significant.

RFC 2119: "SHOULD ... the full implications must be understood and
carefully weighed ...". This requires the implementer to know what the full
implications are. In some cases these implications are obvious, but in this
case they aren't unless you're already experienced with NNTP. So what are
those implications?

Furthermore, as far as I can see, if a client violates the SHOULD, the
real-world implication is that the server isn't required to interoperate
properly with it (for example, it may forget the currently selected group).
Failure to interoperate, surely, is the very exemplar of a MUST NOT?

How about:

| The client MUST NOT issue MODE READER after issuing any commands that
| change the state of the server and, in particular, MUST NOT issue it
| more than once or after any security or privacy commands are issued.

Do you have a problem with MUST here? If so, I don't understand it.

On the server side, I don't believe it is right to advertise a capability
when it is unsafe for the client to make use of it. If the server state has
changed, then either:
* MODE READER MUST NOT be advertised, or
* we must document how MODE READER affects the state.

> I wouldn't implement it that way, no.

But should we be outlawing such implementations? If so, why?

I think you're wrong to say that capabilities can never change under the
feet of the client; certainly nothing in the present wording implies that.
It may be that we want to put restrictions on this but, if so, we need to
think them through and be able to justify them.

---

From: Russ Allbery <[email-masked]>
Date: Sat, 29 Jan 2005 15:09:28 -0800

>     the current and correct information concerning available
>     capabilities at any point during a session by issuing a CAPABILITIES
>     command at that point of that session and processing the response.

> That wording (which came from LIST EXTENSIONS, IIRC) certainly implies
> that the available capabilities can change for reasons other than
> specific commands.

Hm.  Okay, maybe I'm worrying too much about that aspect of things.

>> In practice, note, sending MODE READER after doing a few other things
>> will work and will not pose any interoperability issues; the
>> interoperability issues only arise if MODE READER is sent after
>> AUTHINFO or STARTTLS.

> Or GROUP or LISTGROUP. Or anything else which sets state (admittedly,
> the current selected group is the only state which comes to mind).

In practice, this will also not cause any problems, since either GROUP is
going to fail before MODE READER or MODE READER is going to be a no-op.

>>> situations where it is sensible to violate it, and so client authors
>>> are entitled to know what the implications are so that they can decide
>>> if they are an exceptional case. That opens the whole internal state
>>> can of worms.

> carefully weighed ...". This requires the implementer to know what the
> full implications are. In some cases these implications are obvious, but
> in this case they aren't unless you're already experienced with NNTP. So
> what are those implications?

Haven't we already covered this at great length in this discussion?

Would it help if we just said that MODE READER MAY (but is not required
to) reset the connection to the state that it was in immediately after the
initial connection?

> Do you have a problem with MUST here? If so, I don't understand it.

Yes, I have a significant problem with that paragraph because "commands
that change the state of the server" is undefined.  We can't say something
like that unless we intend to define exactly what commands we're talking
about.

> On the server side, I don't believe it is right to advertise a
> capability when it is unsafe for the client to make use of it. If the
> server state has changed, then either:

So the choice is between fiddling with capabilities some more behind the
back of the client or documenting that MODE READER may reset the state of
the server.  The latter is looking more attractive to me; why not go with
documenting the existing practice?

I guess I don't really care that much; all the solutions are ugly to me in
one way or another, but that's because MODE READER is ugly so that
shouldn't really be a surprise.

> But should we be outlawing such implementations? If so, why?

I guess I don't care enough to argue this at length, and we need to get
past this and move forward with a last call.  I find the idea of
capabilities randomly changing behind the back of the client to be
abhorrent, but maybe it's just me.

IMAP appears to be completely silent on the issue.