ietf-nntp TLS cipher renegotation to NULL cipher

[Jeffrey M. Vinocur]

On Sun, 5 Jan 2003, Ken Murchison wrote:

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

Oh good, I was hoping that we could avoid doing compression (which is 
something that has come up in the past) as yet another layer.


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

This is what I'm hoping.


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

Well, in the scenario above, it doesn't seem like the client can
distinguish between the server saying "renegotiate to NULL or I'm
disconnecting you" and "I'd like NULL but you don't have to".  But I guess
this could be implemented by the server requesting NULL, the client 
complying, and then the client requesting encryption again and seeing if 
it succeeds.

Or maybe this is an absurd situation?  I'm hoping to hear back from e.g. 
Andrew about what might actually occur.


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

(Your second sentence there indicates possible confusion -- I was saying
above that clients should implement the NULL cipher, not that they always
have to be willing to renegotiate to it.)


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

I can't think of any other reason offhand, but performance is definitely 
important to users.


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

*blink*  Ok, I'll raise this in a separate post.


>                                                   The same can be said
> about STARTTLS for that matter.

Well that's definitely true, and there is text to that effect in the 
draft.  I will emphasize it, however.


> server should not request a reneg using the NULL cipher until after
> authentication.

Well sure, but should this be mandated by the spec?


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

Hmm.  I think that will only be a problem with poor client interface 
design.  For example, I'd expect a client to offer three settings, "no 
encryption", "encryption of password", and "encryption of entire session", 
and in that case I can see the middle being a reasonable default.

But I'll yield to the group on this if others agree with Ken.


-- 
Jeffrey M. Vinocur
jeff at litech.org