Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> The security considerations section of this draft has to describe the
> fact that even with this fix, renegotiation does things that will
> surprise application developers, and can cause security
> vulnerabilities for some of them.
> 
> That part we cannot avoid -- some text has to be included.
> 
> It's not absolutely required that the text makes recommendations how
> to avoid those vulnerabilities, but IMHO it would be a bit strange to
> just describe the security problem without saying anything how to
> avoid it...


I agree with this reasoning.

Given the contention on this topic, I would prefer the guidance
to be:

 - non-normative on default behaviour

 - normative (SHOULD) on specific options a TLS implementation
   should offer to applications

Two options where identifying the exact location of renegotiation
in app-data is not necessary and interleaving of app-data and
renegotiation handshake is not a security problem:
  - no renegotiation
  - renegotiation only for identical certificate (chain)  = memcmp()
    (allowing authentication of a previously un-authenticated party)

Defining constraints for changes in identity where the application
has to deal with these changes becomes complex very quickly.

When there is some signaling between TLS implementation and application
(like a callback), and application data that arrives during the
renegotiation handshake is either dropped or leads to failed hanshake,
then a change of identity--even for something as "insignificant" as
a certificate renewal is manageable for the application.

There are issues in the existing SSL & TLS protocol specs that
cause a problem for such semantics: (a) the TLS spec explicitly allows
transfer of application messages interleaved with renegotiation
handshake messages, and (b) the TLS spec indicates that handshake
messages have precedence over application data, without saying
what this means.  Since this precedence is _not_ about processing
at the record layer (in TLS, all messages must be processed in order),
so it can only be about delivery to application.  But here, it
creates a confusion in the wrong direction.  Application data delivered
interleaved with the renegotiation handshake is protected under the
original cipher suite and under the original authentication.
Delaying that data until after authentication seems unreasonable,
because it would require an additional facility to tell the application
at what point in the application data stream the identity change
happened, long after the signaling of the new identity.


When application data delivery is allowed during renegotiation handshake
and the identity change signaling is _NOT_ after successful verification
of the peer's finished messsage, but instead is performed much earlier
in the handshake (such as during processing of the Certificate
handshake message), then this may easily create additional security
problems for an application.

 
-Martin