ietf-nntp TLS cipher renegotation to NULL cipher

[Ken Murchison]

"Jeffrey M. Vinocur" wrote:
> 
> 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.)

Another feature of TLS that might be of interest to those with
bandwith/performance concerns, is that you can negotiate a compression
algorithm.  AFAIK, zlib compression is the only algorithm currently
documented (in an I-D) and implemented in OpenSSL.


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

Since reneg is always a possibilty in TLS (regardless of protocol), I
think mentioning it just for the sake on mentioning it would be silly. 
However, mentioning its intended use and security considerations within
NNTP would be worthwhile.  Also, we should stay away from
implementation-specific issues like OpenSSL's API.


> 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

I don't think we need anything else at the NNTP level.  TLS has its own
handshake protocol, so it should be used.


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

Per RFC 2246 both the client and server can request a reneg anytime, and
either are free to refuse to do so if they wish.  So, I think there is
already enough controls to configure the client/server policy.  Since
this will probably only take place after authentication, we can make
this user specific if necessary.

I'm not a client author, but here's my $.02:


> 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'd make this a SHOULD, with the caveat that it MUST not be available
until after authentication.  Some clients/users may _always_ want the
complete session protected.


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

I'd say MAY.  I'd be interested in hearing when the client would want to
initiate a downgrade, rather than the server requesting it.  Would this
just be for performance reasons?


>       back to a real cipher before beginning any subsequent
>       authentication steps)

What subsequent authentication steps?  I don't think that multiple
AUTHINFOs should be allowed in a single session.  The same can be said
about STARTTLS for that matter.


>     - client software will support renegotiation initiated by the server

Again, SHOULD (this is tied to the first point).  I also think that the
server should not request a reneg using the NULL cipher until after
authentication.

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

I'd say that the default should be encryption for the entire session,
just like other protocols so that we don't mess with user's
expectations.  I think that most user's expect complete privacy when
using SSL/TLS, not just for authentication.

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