ietf-nntp Draft 20 pre-release 2

[Rob Siemborski]

On Thu, 9 Oct 2003, Clive D.W. Feather wrote:

> All comments welcome. In particular, I'd like to know that someone's done
> a through review of 11.6 (new) and appendices C and D.
>
> All of the following issues have been resolved:
> * Section 11.6 now written.

This section is broken in *dire* ways.  It contains a direct contradiction
to section 5.3:

  An NNTP client MUST NOT rely on any cached results from this command,
  either earlier in this session or in a previous session, remaining
  correct. While some extensions are likely to be always available or
  never available, others will "appear" and "disappear" depending on other
  changes. See Section 11.6 for further discussion of this topic.

Where as 11.6 states:

  Therefore it is reasonable for a client to cache extension status
  between sessions...

Why are we saying MUST NOT in one section and "it is reasonable" in
another section?

I believe that 5.3 is correct and that a client MUST NOT rely on cached
versions of the extension list at any time.  This is in line with similar
protocols that offer extension discovery commands.

11.6 is wrong in other ways too:

  In most situations the results from this command will not change from
  session to session.

Forget about session to session, within a single session the contents of
LIST EXTENTIONS can change.  For example, following STARTTLS or the
establishment of a SASL security layer.

Other protocol's SASL profiles explicitly state that clients MUST throw
out any information they have gained about the other side's capabilities
after a security layer is established, to avoid an active MitM attack.
NNTP isn't different in this way.

This is highly unacceptable behavior that I strongly suspect will not make
it past the IESG.  The only solution to this is to keep the text of 5.3
and not encourage implementations to cache results at any point in the
document (remove 11.6, or replace with a strong anti-caching stance).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3 at andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----