ietf-nntp TLS cipher renegotation to NULL cipher

[Jeffrey M. Vinocur]

There is a new issue raised below that I'd like people to discuss.

It is of particular interest to people who want TLS protection only on the
authentication step, and to client authors who may be more in touch with
their users than I am.

(Note, by the way, that I don't know all that much about TLS, so if I say 
anything that doesn't make sense, please correct me.)


On Sat, 4 Jan 2003, Ken Murchison wrote:

> FYI, I spent some time hacking the TLS renegotiation after
> authentication stuff into the Cyrus NNTP server and test client, and it
> _is_  possible using OpenSSL.  Its pretty straight forward adding this
> to the server, 

Slick.  I have no objections to seeing the DSS draft resurrected in the
future if people find that the prefer it, but I think given the above, we
don't need to block on DSS for AUTHINFO SASL to proceed.


>                but the client needs to be made aware of renegotiations
> (checking error code of SSL_read()) and must provide the NULL ciphers. 

Does anyone feel we should have verbiage discussing the possibility of
renegotiations in the STARTTLS draft?  For example, a warning to check for 
the above, or a suggestion/requirement that clients have a configuration 
option to request renegotiation to NULL.

How do people see this renegotation being used?  I'm wondering in 
particular if I need to add something else at the NNTP level; what happens 
if a server admin wants to allow users to protect their entire connection, 
but wants most of them to drop to the NULL cipher after authentication?

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

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

    - client software will support renegotiation initiated by the server

Does that make sense?  Should I replace "will" with SHOULD or MUST in any 
of the above?  What should be the default configuration (I'd say 
only-for-authentication)?




P.S.  Ken, thanks for pursuing this.  I think renegotation is important to
      pin down one way or another.

-- 
Jeffrey M. Vinocur
jeff at litech.org