ietf-nntp TLS cipher renegotation to NULL cipher

Russ Allbery rra at stanford.edu
Sun Feb 9 21:45:38 PST 2003


Jeffrey M Vinocur <jeff at litech.org> writes:

> Does anyone feel we should have verbiage discussing the possibility of
> renegotiations in the STARTTLS draft?

I do think that we should discuss its possible applications in the NNTP
context, and in particular that we should talk about renegotiating to the
NULL cipher after authentication occurs.  It's probably worth putting
something in there about how most NNTP traffic carries completely public
information and can be high-volume, so there's often no reason to encrypt
it and some performance penalty for doing so, but some NNTP applications
may deal with private data and need a higher level of protection.

> Here's what makes the most sense to me at the moment, not having really
> thought it through very much:

>     - client authors will provide the NULL cipher

I agree with Ken that this makes the mose sense as a SHOULD, in that some
clients may be designed entirely for private NNTP hierarchies that are
always encrypted and there's no reason for them to have to implement
something that they'd never use.

>     - client software will be configurable as to whether to use encryption
>       only for authentication or all the time (implemented by attempting
>       renegotiation to NULL after authentication is complete, and again
>       back to a real cipher before beginning any subsequent 
>       authentication steps)

I think this is a MAY implement for the server and a SHOULD implement for
the client (except for the part about multiple authentication steps, which
is being discussed in the other thread), because the performance issue is
more severe for the server.  That also parallels the SHOULD above for the
NULL cipher.

I don't think we can reasonably go so far as to require clients to be
willing to negotiate down to the NULL cipher after authentication in the
standard, since there are cases where that's definitely the wrong thing to
do.

> What should be the default configuration (I'd say
> only-for-authentication)?

I'm not sure we should explicitly state a default, and instead discuss
both the above point about how most NNTP traffic is public and Ken's point
about how most users expect SSL to protect their entire session and to
leave it up to the individual software implementors.

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



More information about the ietf-nntp mailing list