ietf-nntp Draft 20 pre-release 2

[Clive D.W. Feather]

Rob Siemborski said:
>> * Section 11.6 now written.
> 
> This section is broken in *dire* ways.  It contains a direct contradiction
> to section 5.3:
[...]
> Why are we saying MUST NOT in one section and "it is reasonable" in
> another section?

We are saying it MUST NOT *rely* on the cached results. Note that word.

It is reasonable (except in the security arena, see below) to cache the
results from LIST EXTENSIONS. It is reasonable for the client to use the
cache to guide its actions. It is WRONG for it to assume that the cache
tells the truth and the whole truth.

If you read those quotes in context, this should be clear. In particular,
note that the second one is followed by:

    However, such implementations MUST cope gracefully with the cached
    status being out of date

> I believe that 5.3 is correct and that a client MUST NOT rely on cached
> versions of the extension list at any time.

I agree. I don't see that 11.6 contradicts this.

However, if you can suggest better wording for 11.6 I would be very
interested; it's important that this is clear to everyone.

> 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.

That "in most situations" is sub-optimal. It ought to be reworded to talk
about server state and context. While STARTTLS is one case, there are
others in the core protocol - for example, MODE READER can change things as
well. I will think about this. [*]

But once you've established TLS, or done MODE READER, the results will
probably not change from the last connection in this state.

> 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.

No, it isn't. Well, not completely different.

But such statements belong in the SASL extension specification rather than
in the core protocol.

> 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).

I don't understand your vehemence here. We agreed a month or so back that
security issues were different and caching had to be thought through
carefully in that respect.

But *outside* the security arena, what is the problem with caching. Note
that most NNTP connections are made without the use of security at all,
authenticated at most by IP address. Given the (semi-)public nature of
most NNTP servers, this is to be expected.


[*] Russ, during the last discussion I floated the idea that LIST
EXTENSIONS could have a mode that provided contextual information about
extensions. Something like this:

    [C] LIST EXTENSIONS MOREINFO
    [S] 202 Extensions list with more information
    [S] + AUTHINFO USER
    [S] ! SASL CRAM-MD5 NTLM DIGEST-MD5 PLAIN
    [S] - SASL CRAM-MD5 NTLM DIGEST-MD5
    [S] + STREAMING
    [S] - STARTTLS
    [S] .

where:

    + = this extension is always available
    ! = this extension is available now, but not in some other states
    - = this extension is available in some other states, but not now

and to which we could perhaps add:

    ? = this extension is available now, but not in some other states;
        for security reasons clients MUST NOT cache this information

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646