[CHANNEL-BINDING] Avoiding CB sync problem via server-side solution (was Re: Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW))

[Nicolas Williams <[e-mail]>]

On Tue, Mar 23, 2010 at 10:03:06PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > But what is the trigger?  Key aging?
> 
> A renegotiation request from the peer, as I understood it.

The peer being the TLS server.  What's the trigger on the server side?

In most apps authentication happens soon after establishing the channel,
so re-keying as a trigger is out of the question.  That leaves TLS
authentication using a user cert, which is a form of authentication in
itself, and which the server application ought not request
asynchronously from application-layer authentication.

It's possible that in practice we never authenticate before
re-negotiation because the server doesn't ever need to request
re-negotiation before authentication.  The spec would still need
significant amounts of verbiage about this situation, but at least
avoiding the situation would be much easier because avoidance could be
done using existing APIs on the server-side instead of requiring new
APIs on the client side.

(Of course, if it never happens, then it seems much less necessary to
change the spec for tls-unique to say that re-negotiation changes the
channel's CB.  But it might turn out to always happen for future app
protocols, in which case a discrepancy amongst implementors would be
bad.  Also, there exist SASL apps allow for re-authentication at any
time, so we must agree on one approach.)

I'm much more comfortable with avoiding the CB synchronization problem
by using existing APIs on the server side.  Do we agree that this is
possible and desirable?  If so I'll make the change.

Nico
--