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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > 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.
> 
> If your TLS API was able to tell you exactly where in the application
> data stream a renegotiation has completed successfully, you would
> be able to apply the original security parameters to the data received
> prior to the renegotiation, and then switch to the new parameters for
> the data received after the renegotiation.

What about the application data sent between the ChangeCipherSpec
and the Finished messages?  It certainly must be encrypted by
the crypto parameters of the new session.  But it can not be
considered authentic before the finished messages have been
verified.  And when the finished messages verify, then I consider
it inappropriate to associate that data with the _previously_
authenticated session&identity.

Since the current SSL&TLS specs are completely ambiguous, you can
not claim "if your TLS API was able to tell you exactly where in
the application data stream", because currently no such semantics
exist!  Two independent implementations of TLS that claim to
tell you exactly where the position is may identify entirely
different positions -- and with the current spec, it is impossible
to decide where the position should be.


> 
> That would catch the MITM attack being discussed now.

We're going to plug that MITM attack with secure renegotiation.

But that will not affect the miserable ambiguity for where the
original session ends and the new session starts if we do allow
established identities to change during renegotiation.

To fix that, we will have to spell out the precise semantics
in a specification.  IMHO, the cleanest would be to disallow
application data transfer during a renegotiation handshake.


> 
> > 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.
> > 
> >    the client must not send any application data between
> >    ClientHello and the client's Finished message
> > 
> >    the server must not send any application data between
> >    ServerHello and either no_renegotiation alert or
> >    the server's Finished message 
> > 
> >    the client must drop all application data received
> >    between ServerHello and either no_renegotiation alert
> >    or the server's Finished message
> > 
> >    the server must drop all application data received
> >    between the ClientHello and the client's Finished message
> 
> When I first implemented TLS, the only reason I could envision for
> renegotiation was to refresh the symmetric keys, so I made it work
> asynchronously.  I wrote about it in this message:
> 
>    http://www.ietf.org/mail-archive/web/tls/current/msg04042.html
> 
> With this design, application data can flow at nearly full speed while
> a renegotiation is taking place.  Requiring all data to stop flowing
> during a renegotiation, may be unnecessary in some situations.

If you lock down established identites, then I do not see a problem with this.

For a delayed TLS client-cert authentication, this implies the semantics
that the newly established identity assumes responsibility for everything
that has been sent over the previous session.  (The assumption that
is currently a problem for servers doing renegotiation without a
cryptographic binding between previous and renegotiated session.


> I do see however, that data probably needs to stop flowing after sending
> a Finished message until receiving the peer's Finished message, but
> that affects only one direction and last for one round trip, not two.

Why Finished?  I think its everything following the ChangeCipherSpec.


> 
> When you add changing client credentials to the mix, then data flow
> probably has to stop, but that is really an application-level decision.
> Also silently dropping data never seems like the right thing to do IMHO.

_I_ did not write _silent_ dropping.  Dropping and aborting is fine.
Dropping in the sense of "MUST NOT make it available to the application".

I said "drop" after having previously specified that the other
side MUST NOT send during the handshake.  That MUST NOT send app data
directly translates to a requirement for the receiver to drop that
data.  Sending an alert when that happens and closing the connection
is fine with me.


>
> > Are there currently applications that actively abuse the possibility
> > provided by the spec to interleave application data and handshake
> > messages of a TLS renegotiation handshake (provided that the
> > TLS implementation that (a) they're using and (b) they're talking
> > to actually allow this.  The fact that the spec says so, doesn't
> > mean that everyone has implemented it in this fashion (since it
> > is complex,difficult and possibly insecure)?
> 
> Yes, see the above referenced message.  But I don't agree that it's
> abuse since that is what the spec. says to do.


I certainly didn't not want to blame you for implementing exactly
what the TLS spec says in your TLS implementation.

I'm sorry if I wrote it that way.

I'm wondering whether there are application that actively abuse
this feature and would break if the TLS implementation would exhibit
semantics similar to those I outlined above and fail with an error
if the TLS implementation would reject application data while
performing the renegotiation handshake.


-Martin