ietf-nntp Draft 20 pre-release 2

[Russ Allbery]

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

> While I've used "ENCRYPT" (which I'll change to "XENCRYPT") and
> "XSECRET" for clarity, this was originally explained as applying to TLS
> and SASL.  A client shouldn't use SASL PLAIN on a non-TLS link because
> of eavesdroppers. It also needs to use LIST EXTENSIONS to determine
> which SASL methods work. If it caches the answer from a TLS link and
> uses it on a non-TLS link, it exposes its password.

Ah, I see what you're getting at.

> I've added:

>         [C] XSECRET   fred flintstone
>         [S] 483 Only permitted on secure links

>     exposing the password to any eavesdropper.
> ++  While the primary cause of this is passing a secret without first
> ++  checking the security of the link, caching of LIST EXTENSIONS results
> ++  can increase the risk.

> Does that help?

It helps, but it feels like a roundabout way of getting at the point,
since it's talking about things like link security that aren't even in
scope in the rest of the draft.

I'd rather avoid the whole issue of what mistake is primarily at fault and
just say something like:

    Therefore a client that is relying on a privacy extension to protect
    private information, such as a cleartext password, MUST NOT rely on
    any cached LIST EXTENSIONS results and MUST follow whatever additional
    rules are laid out in that extension for checking the security of the
    link and the identity of the server immediately beforehand.  How such
    a check is done will, of course, depend on the particular facilities
    available from the server and documented as part of the extension.

But I'm also a bit leery of repeating something like this, since it could
be read as weakening the previous, more general statement about all
caching of security and privacy extensions.  Hm.

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