ietf-nntp Draft 20 pre-release 2

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> I can now see that that "is advised to" is far too weak and I have changed
> it to:

>     Therefore a client sending private information, such as a cleartext
>     password, to a server SHOULD check the security state of the link
>     and the identity of the server immediately beforehand and SHOULD NOT
>     rely on the (cached) results of any previous check. How such a check
>     is done will, of course, depend on the particular facilities
>     available from the server.

> It's not clear to me that we can say MUST and MUST NOT rather than SHOULD,
> because it isn't an interoperability issue. However, if you tell me that
> MUST is compatible with RFC 2119, I'll happily make the change.

Hm.  This section seems unrelated to the whole LIST EXTENSIONS bit, so
maybe there are more issues happening here simultaneously than I was aware
of.  I'm not entirely sure what this section means; are we talking about
situations where the security level of a TLS-protected connection may be
negotiated downwards?  LIST EXTENSIONS isn't how one would determine the
security state of the link; that would be something internal to the TLS
protocol.

RFC 2119 says that MUST may be used to limit behavior which has potential
for causing harm, and security vulnerabilities are certainly harm, so I
think we're quite justified in using MUST and MUST NOT in situations where
security is at stake.  But I'm not sure I entirely understand this section
and its relation to LIST EXTENSIONS.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>