Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

[Nicolas Williams <[e-mail]>]

On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote:
> I whish there was a constraint that an identity/certificate that has
> been established for a party during the TLS handshake MUST not change
> during re-negotiation, but _none_ of the current SSL&TLS specs has
> such a constraint, so the issue of identity change is currently
> dumped as a responsibility onto the application.
> 
> I am certainly in favour of locking this down for the renegotiation.
> I believe it is irresponsible to leave this un(der)specified as it is.

+1

This is the right time to add such a constraint.

I wouldn't be surprised if there are clients (for IMAP? LDAP?) that take
advantage of this to allow the user to switch "hats" without
reconnecting though.

> As previously described in another message, the current spec has a
> requirement that additonal application data may be arbitrarily
> interleaved with a renegotiation handshake.  I think this requirement
> makes a security assessment of the protocol impossible for changing
> identities.

Or at least really difficult.

> Personally, I would it find much cleaner if the semantics for the
> renegotiation would require the TLS peers to suspend transmission
> of application data while performing TLS renegotiation,
> i.e.

+1

This is the right time to add such a constraint.

Unlike a "authenticated identities can't change" constraint, this could
be implemented without conceivable app protocols being broken, I think,
but it may require API changes for some implementations, and that it may
put this change out of reach.

Nico
--