Re: [TLS] TLSrenego - current summary of semantics and possibilities

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > It is possible that a TLS client may not want to assert the TLS extension
> > Renegotiation_Info in an initial ClientHello because of interoperability
> > concerns with an installed base of not-quite-spec-compliant servers.
> 
> Then it will end up buying a lot of pizza.

What you're asking for is to discontinue talking to the entire installed
base of SSL&TLS implementations.  i.e. clients should only talk to
updated servers (which means they must be updated clients).

What about a transistion period?
(A world-wide "SSL/TLS flag day" is probably unlikely) 

How do you determine the end of the transition period, i.e.
the point in time where clients discontinue to servers that were
not updated?


> 
> Simply finishing the *initial* handshake completes the attack!  (The
> server saw it as a renegotiation, not the client.)

But you do realize that it is an attack on the server?

And do you further realize, that it is a problem of the server
that request or at least allow renegotiation -- those that reject
renegotiation are _not_ vulnerable.


The MITM only makes you talk to someone.

Considering how careless some security folks invent means to coerce
someones software to talk to someone else (e.g. certificate URL TLS extension,
AIA in X.509 certs), I don't feel it is fair to hold the TLS clients
responsible for the problem.

What you're asking for means that the Browsers should discontinue
their re-connect fallback with a SSLv3 ClientHello, because the
MITM could be able to coerce the browsers to do it.


> 
> To protect against this, the only thing that a client can do is include
> the empty renegotiation info extension.  If the server returns it and
> the handshake completes, there is no MITM.  In fact if you were to then
> renegotiate, you wouldn't need the extension (!) because you are already
> certain that the handshake was with the server and not the MITM.

HUH?  The Renegotiation_Info is required for cryptographic binding
during the renegotiation handshake.  Without it, there is zero protection.

> 
> There are a few possible results of sending the extension:
> 
>      a) the server responds with the extension
>      b) the server responds without including the extension
>      c) the server "crashes" because of the extension

You have forgotten
       d) the server sends a fatal handshake alert
       e) the server closes the network connection

> 
> > Overloading ("abusing") the semantics of other regular elements
> > of an SSL/TLS handshake that have a lesser likelihood to upset
> > legacy servers.
> > 
> >    - Assign one (or two) specific ciphersuite IDs that the client
> >      can include in the ciphersuites list which signal the clients
> >      notion of the connection state (initial vs. renegotiation)
> >      to the server.
> > 
> >    - Assign one (or two) compression algorithm IDs that the client
> >      can include in the supported compression algorithms list which
> >      signal the clients notion of the connection state (initial vs.
> >      renegotiation) to the server.
> 
> I would not like to see this kind of solution.  If code has to change,
> Do The Right Thing.


The IETF should provide solutions to the _real_ world.
Limiting our solutions to an ideal world of academic purity will
hurt the entire community of end users around the world.


To me it looks like the TLS WG did not sufficiently care and push
that implementations support the "official" extensibility provided
already in the SSLv3 protocol (ClientHelloExtension), therefore
we may have to resort to (ab)using the purpose of other
extensibility options provided in the protocol that have a
significantly higher interoperability among implementations.

Assigning a ciphersuite IDs for the purpose of signaling
support for TLS extension Renegotiation_Info in a initial
handshake on a connection (as seen by the client) and
including that ID in the ciphersuites list offered by the
client might offend/confuse less of the old servers than a TLS
client extension or a client.version != 0x03,0x00

It might be OK for an updated client to always send the
TLS extension Renegotiate_Info with the verify_data from
the client.finished message on a renegotiation handshake.
In that case, we would not need to signal the clients
notion of "initial vs. renegotiate" with an additional
re-purposed ciphersuite ID.


Even if _you_ can update all _your_ clients and server that
you are using, this does not make the other non-patched (but also
not vulnerable) servers go away.  The problem that were facing
right now is not caused by those servers.  It's _our_ fault
(Netscape and the IETF TLS WG), because _we_ created this problem
with a design flaw in the protocol.  So if _we_ are not trying to
provide a solution in a fashion that breaks the least amount of
the installed base, then we're not acting responsibly.
That would amount to shifting blame / passing the buck, it would
not be the engineering solution that the community expects from us.


When thinking about re-purposing other areas of the exiting protocol,
our concerns should be more along the lines: what will break if
we do that?  who might be confused by this change, and what problems
may arise from such confusion?  can the re-purposing lead to a new
security problem by itself?  How good can we interop-test this?

Personally, I think that religious beliefs about protocol purity
are much more important for new protocol design and forward
interoperability issues.  They are at most marginal when
trying to fix a problem that is more than 14-years old would
require then entire world to update in order to protect
a small amount of people against a small amount of servers
that will irresponsibly continue to make assumptions accross
TLS session boundaries of an unprotected TLS renegotiation.


-Martin