Subject: [NNTP] Extension snapshots 3

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

Here are the latest versions of the extensions docs.  Hopefully all 
changes mandated by the recent base draft text and list traffic have 
been implemented.  Notable changes since the pre2 drafts are listed below.

http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-06pre3.txt
http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-streaming-03pre3.txt
http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-04pre3.txt

All drafts:

- syncd ANBF and IANA stuff with base draft
- updated CAPABILITIES in examples
- removed reader/transit/general-use command stuff

AUTHINFO:

- extended the length of the AUTHINFO SASL command to accommodate large 
initial responses
- better discussion of interaction with MODE READER and MODE-READER

STARTTLS:

- better discussion of interaction with MODE READER and MODE-READER

STREAMING:

- split first sentence of TAKETHIS description in two

-- 
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 Murchison <[email-masked]>
Date: Wed, 12 Jan 2005 11:08:57 -0500

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

I'd appreciate comments on these by the end of the week.  I'll be on 
vacation 1/16 - 1/30 and I'd like to submit these to the I-D editor 
before I leave.

The only notable change to the above docs is a slight re-wording of the 
SASL mechanism list advertisement after authentication text (posted in 
another thread).

---

From: Ken Murchison <[email-masked]>
Date: Fri, 14 Jan 2005 14:18:01 -0500

> SASL mechanism list advertisement after authentication text (posted in 

I was completely underwhelmed by the feedback on these, but since I'm 
going to be offline more often than not over the next two weeks, I went 
ahead and submitted these to the I-D editor.  They should show up in the 
repository early next week.  I have also posted them under 
http://www.oceana.com/ftp/drafts

The only other change that I added is an outstanding issue to STREAMING 
asking whether or not there are any security issues that need to be 
discussed.  For instance, can a DoS attack be launched on a 
non-streaming server by bombarding it with TAKETHIS?

---

From: Russ Allbery <[email-masked]>
Date: Mon, 17 Jan 2005 13:15:01 -0800

> http://www.oceana.com/ftp/drafts

They looked fine to me.

> non-streaming server by bombarding it with TAKETHIS?

I don't think there's any issue here that doesn't look like the issues
involved with just about any TCP-based service, so I don't see any need to
make a specific mention regarding STREAMING.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 18 Jan 2005 06:50:42 +0000

Ken Murchison said:
> ahead and submitted these to the I-D editor.

I'm sorry, but I've been overwhelmed with other things. I will try to look
at them this week.

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 20 Jan 2005 05:17:32 +0000

Ken Murchison said:
> Here are the latest versions of the extensions docs.

Using the official versions at the I-D repository.

General

Your various CAPABILITIES examples need to be audited against the
latest [NNTP], to ensure that, for example, they have the correct LIST
arguments based on the other capabilities.

AUTHINFO

2.1. First paragraph, change "is not advertised" to "MUST NOT be
advertised".

STREAMING

2.3.2: the last sentence contradicts the first. Since the first sentence
says it MUST support MODE STREAM if streaming works, the SHOULD in the last
sentence makes no sense. Just delete the last sentence.

3: you need syntax for simple-response-content:

    simple-response-content =/ streaming-response-content

    streaming-response-content = ("238" / "239" / "431" / "438" / "439")
        SP message-id

4. The relevant codes should have the line:
    1 argument: message-id
added; compare 111 or 222 in [NNTP].

STARTTLS

2.1. The sentence "However, ..." needs adjusting. Try:

    However, the capability MUST NOT be advertised once a TLS layer
    is active (see section 2.2.2.2), or after any alternative mechanism
    that installs a security layer (e.g. [NNTP-AUTH]).

Note the change to MUST NOT. The second bit is because, in principle,
STARTTLS after a USER authentication, or an SASL authentication that
does *not* set up a security layer, should be fine.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 31 Jan 2005 10:42:18 -0500

> arguments based on the other capabilities.

Added LIST OVERVIEW.FMT to STARTTLS draft and LIST HEADERS to STREAMING 
draft.  Did you see anything else missing?

> sentence makes no sense. Just delete the last sentence.

OK, I see your point.  What I'm trying to say is that MODE STREAM isn't 
required (because its deprecated by CAPABILITIES), but if supported, it 
returns 203.  What if I change the first sentence to:

"If a server supports the MODE STREAM, CHECK, and TAKETHIS commands it 
MUST return a 203 response to the MODE STREAM command (or 501 if an 
argument is given) and MUST NOT have any other effect.

> does *not* set up a security layer, should be fine.

Not true.  Successful STARTTLS resets the state of the connection, so we 
don't allow STARTTLS after *any* authentication.  Here's the current 
sentence:

"However, this capability MUST NOT be advertised once a TLS layer is 
active (see section 2.2.2.2), or after successful authentication 
[NNTP-AUTH]."

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Mon, 31 Jan 2005 17:50:02 -0500

> argument is given) and MUST NOT have any other effect.

There's something askew grammatically there (the implicit subject of 
the last clause is "a server," but the verb is "have").  I tried 
rephrasing:

"If a server supports the MODE STREAM, CHECK, and TAKETHIS commands, it 
MUST return a 203 response to the MODE STREAM command (or 501 if an 
argument is given), [but / and] the command MUST NOT have any other 
effect."

But that's a little awkward regardless of if I use "but" or "and"?  I'm 
having trouble with this one.

-- 
Jeffrey M. Vinocur
[email-masked]