ietf-nntp Draft 20 pre-release 2

[Ken Murchison]

Clive D.W. Feather wrote:

> Jeffrey M. Vinocur said:
> 
>>I do support Clive's point that this *is* a protocol document and thus
>>it's not really well-formed (or even in our scope?) for us to prohibit
>>caching per se.  
> 
> 
> Indeed. It's also an untestable requirement.
> 
> Basically, if a client screws up security, is it because they cached when
> we told them not to, or for some other reason? Both point to problems with
> the author.
> 
> 
>>An alternative phrasing along the lines of "clients MUST send LIST
>>EXTENSIONS before using ..." would probably be more appropriate.  Or maybe 
>>we should emphasize that each extension document needs to state whether or 
>>not LIST EXTENSIONS is required before use of that extension, and remind 
>>extension document authors that security extensions should invoke that 
>>requirement.
> 
> 
> Firstly, we talked that one out before. This implies that LIST EXTENSIONS
> can turn extensions on, and that is a strict no.

I agree that LIST EXTENSIONS should not be used to enable extensions, 
but I don't think that is what we're talking about (at least I hope not).

LIST EXTENSIONS SHOULD be used by a client before using an optional 
capability so it knows if its available or not.  This potentially saves 
multiple round trips of trial and error.

I think expending the one round trip for LIST EXTENSIONS makes a lot 
more sense than wasting them on commands that the server doesn't 
support.  I suppose somebody will come up with the idea to cache the 
fact that HDR or OVER failed and never try it again, but that seems 
ridiculous.

I propose that we remove ALL reference to caching and be done with it. 
It sounds like client authors are going to do what they want anyways, so 
why encourage or discourage them.

IMAP clients typically make multiple connections for one "session" and 
none of those authors have a problem with sending CAPABILITY for each 
connection.

> Secondly, LIST EXTENSIONS is actually a symptom, not a cause. The problem
> we're trying to solve is clients that send passwords over an insecure link.
> If a client uses SASL PLAIN (or whatever) without establishing TLS first,
> it's broken. It doesn't matter *why* it did that. People seem to be
> assuming that clients will use LIST EXTENSIONS to know what security
> mechanism is there. What if they don't?

They are severely broken, and nobody should use software written by such 
authors.

> The right place to warn about this is in the document that defines SASL
> (or whatever).

Agreed.

> We agreed this was important enough to put a note in the
> base document, and I'm fine with that. The present wording is clear that
> you SHOULD NOT do this, and I'm happy to make that MUST if Russ is.

Let's just avoid the subject in the base document altogether (like the 
IMAP and POP RFCs), and we're done.



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