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

[Michael D'Errico <[e-mail]>]

> What about the application data sent between the ChangeCipherSpec
> and the Finished messages?

I don't think application data should be (allowed to be) sent between
ChangeCipherSpec and Finished.  Should it be required for a fatal alert
to be sent if such data is received?  That would make sense.

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

I disagree.  When you receive the ChangeCipherSpec, the new parameters
take effect; the Finished message has to immediately follow to verify
the handshake succeeded.  Verification of the Finished message signals
the end of the old session and the beginning of the new.

This would require no application data be sent between CCS and Finished,
but that should be a requirement anyway.  And it would be surprising
to learn about an implementation that doesn't generate Finished
immediately after generating the CCS.

>> That would catch the MITM attack being discussed now.
> 
> We're going to plug that MITM attack with secure renegotiation.

Sure, but my point was that if these semantics had existed, this MITM
attack might not have been possible.  Or rather, it would have been
easier to see the problem of applying the new credentials to the old
request retroactively.  I think it would be valuable for an API to add
these semantics even with the addition of 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.

The CCS/Finished tells you where to draw the line.

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

This should be up to the particular application.  If rekeying is the
reason for the renegotiation, you want to keep data flowing as much
as possible.  For changing identities, an application might forbid
data flow, or it may not.

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

OK, but I would advocate MUST make available to the application and
provide an indication of where the renegotiation finished.

The problem with HTTPS is that the request line is sent before the
handshake even starts, and then once completed, that request line is
reused under the new credentials.  HTTP(S) needs a way to ask the
client to resend its entire request.

Mike