Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Here is my analysis of the requirements and implementation efforts 
> for TLS extension RI with magic cipher suites value (MCSV), based on
>  my recent experiences from implementing 
> draft-mrex-tls-secure-renegotiation-03 in OpenSSL-0.9.8l and looking
>  at the early implementation of draft-rescorla in the 
> OpenSSL-0.9.8-snapshot.
> 
> The purpose of the MCSV is:
> 
> - provide interop with installed base of old, extensions-intolerant 
> servers (original&correct SSLv3 and "defective" TLSv1.0)

The draft-freier-ssl-version3-02.txt says to ignore data after the
Client Hello, which implies extension-intolerant SSLv3 servers are
defective, too. Not that it really matters at this point. Had you
mentioned something about an earlier version not saying that?

> - provide protection from downgrade attacks (extension-less 
> ClientHello or SSLv2 ClientHello)

It enables clients which choose to send an SSLv2-compatible Client Hello
to do so and indicate support for RI.

> - provide protection in backwards interop scenarios (renegotiation 
> requested by old servers).

It will never be safe to conduct renegotiation with a remote party in
the absence of negotiated RI.

The expectation is that clients and servers will be transitioned into
"strict mode" at the earliest opportunity.

> in order to reliably provide this,
> 
> - MCSV is defined to represent an empty TLS extension RI
> 
> - MSCV MUST be included in *ALL* initial ClientHello handshakes 
> messages _plus_ all renegotiation ClientHellos in backwards interop 
> scenarios (independent of full handshake or session resume).

MCSV or an empty RI extension should be sent in

> - empty TLS extension RI MUST NOT be sent, ever!

No, you just shouldn't send it if you prefer to interop with old, broken
servers. Lots of clients (browsers, etc) currently do send extensions on
Client Hello, so they may never choose to send MCSV on those connections.

It is hoped that at some point in the future, extension-intolerant (and
-ignorant) servers will be insignificant and the MCSV can stop being
sent by clients.

Yes, the MCSV is a work-around for old broken servers. This work-around
does not constitute the endorsement of brokenness by anyone. It's simply
that in this one bugfix we are choosing to be extra accommodating.

> - TLS extension RI with Client.Finished.verify_data in ClientHello -
>  MUST NOT be sent on renegotiation handshakes in backward interop 
> scenarios with old servers which could otherwise break

They are already broken. It's better to break them in a way that doesn't
represent a vulnerability.

There's no safe way to renegotiate with a remote party that doesn't
properly use RI on all handshakes.

To the extent that both parties have an interest in ensuring the
connection is secure against MitM attacks, it's not even safe to
complete an initial handshake and set up a connection with a remote
party that doesn't properly use RI on all handshakes.

Realistically, people will need a temporary "compatible mode" in place
during deployment of the patch. But you don't gain much actual security
in that mode.

> - MUST be sent in all other renegotiations

All renegotiations.

> If the spec would require that an empty TLS extension RI in a 
> ClientHello MUST be completely ignored, then _everyone_ can save 5-10
>  LoC.

Why would you want to ignore that a client is attempting to negotiate
the use of RI?

> There is a significant difference between extensions-tolerant and 
> extensions-support.  Extensions tolerant means, that a server will 
> not choke on a ClientHello handshake message, but instead simply 
> ignore all data following compression methods compliant to the 
> provision in the updated-but-never-published SSLv3, TLSv1.0 and 
> TLSv1.1 specs.
> 
> In order to implement secure renegotiation with TLS extension RI a 
> "generic" TLS extensions parser (~150 LoC) is necessary to find the 
> TLS extension RI among other extensions, process it and create and 
> process the TLS extension RI reply.  Support for other TLS extensions
>  and API-level access to TLS extensions is completely out-of-scope 
> for the following.

Yep. They have to write a few lines of code to implement a tiny part of
the June 2003 RFC 3546 on TLS extensions.

> Adding MCSV to ClientHello on the client and parsing MCSV from the 
> ClientHello on the server will typically be <10 LoC each.
> 
> Creating an processing an empty TLS extension RI on the ServerHello 
> is also typically <10 LoC each for extension-less implementations.

So you're saying that an implementor who has let their code rot for the
last 6.5 years could save 140 LoC?

Personally, I don't find that to be a primary consideration.

> Types of TLS peers in the current installed base:
> 
> 1.)  old TLS client, no extensions, no renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.

> 2.)  old TLS client, no extensions,    renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.
* Possibly vulnerable to a client-side renegotiation attack.

> 3.)  old TLS client,    extensions, no renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.

> 4.)  old TLS client,    extensions,    renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode server which allows renegotiation.
* Vulnerable to credential stealing when supplying client auth and
routed by the attacker to an unpatched or compatible-mode server which
allows renegotiation.
* Possibly vulnerable to a client-side renegotiation attack.

> 5.)  old TLS server, extensions-intolerant, no renegotiation

* Broken according to every spec published in the last 13 years.
* Possibly vulnerable to a client-side renegotiation attack.

> 6.)  old TLS server, extensions-intolerant,    renegotiation

* Broken according to every spec published in the last 13 years.
* Vulnerable to injection when talking to an unpatched or
compatible-mode client.
* Possibly vulnerable to a client-side renegotiation attack.

> 7.)  old TLS server, no extensions,         no renegotiation

* Possibly vulnerable to a client-side renegotiation attack.

> 8.)  old TLS server, no extensions,            renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode client.
* Possibly vulnerable to a client-side renegotiation attack.

> 9.)  old TLS server, extensions,            no renegotiation

* Possibly vulnerable to a client-side renegotiation attack.

> 10.) old TLS server, extensions,               renegotiation

* Vulnerable to injection when talking to an unpatched or
compatible-mode client.
* Possibly vulnerable to a client-side renegotiation attack.

> The server patches that are currently applied in the field are (6) ->
>  (5) (8)  -> (7) (10) -> (9)

Reasonable to assume.

> Additional types of TLS peers when TLS extension RI is implemented:
> 
> 11.) updated TLS client, RI-minimal,    no renegotiation

Could you explain what you mean by RI-minimal, RI-only, and "extensions".

> 12.) updated TLS client, RI-only,          renegotiation


> 13.) updated TLS client,    extensions, no renegotiation
> 
> 14.) updated TLS client,    extensions,    renegotiation

> 
> 15.) updated TLS server, RI-minimal,    no renegotiation
> 
> 16.) updated TLS server, RI-only,          renegotiation
> 
> 17.) updated TLS server,    extensions, no renegotiation
> 
> 18.) updated TLS server,    extensions,    renegotiation
> 
> 
> 
> Effect of requiring MCSV on implementation effort -- for 
> non-renegotiating servers:
> 
> If we require MSCV on _every_ ClientHello then the update 
> (5),(6),(7),(8) -> (15) amounts to ~20 LoC the update        (9),(10)
>  -> (17) amounts to ~40 LoC
> 
> If we do not require MCSV on _every_ ClientHello then the update 
> (5),(6),(7),(8) -> (15) amounts to ~80 LoC the update        (9),(10)
>  -> (17) amounts to ~60 LoC

> Effect of requiring MCSV on implementation effort -- for 
> non-renegotiating clients:
> 
> If we require MCSV on _every_ ClientHello, then the update (1),(2) ->
>  (11) amounts to ~20 LoC (3)     -> (13) amounts to ~40 LoC
> 
> If we do not require MCSV on _every_ ClientHello, then the update 
> (1),(2) -> (11) amounts to ~80 LoC (3)     -> (13) amounts to ~60 LoC

Those tiny LoC differences are not significant, especially considering
the margin of error for those types of things. Usually you're lucky to
get within a factor of two.

They certainly don't give a realistic indication of "level of effort".

> guestimates about secure rengotiation efforts:
> 
> Servers: these are independent of whether MCSV is required (10) -> 
> (18)  maybe ~180 LoC (6),(8)  -> (16)  maybe ~200 LoC (6),(8)  -> 
> (18)  maybe ~250 LoC
> 
> Clients: these are independend of whether MCSV is required. (4)  -> 
> (14)  maybe ~180 LoC (2)  -> (12)  maybe ~200 LoC (2)  -> (14)  maybe
>  ~250 LoC

I think the conclusion that we can draw from those numbers is that it's
more code than fixing a missing semicolon, and less code than a
medium-sized coding project.

Looks pretty reasonable for a bug fix to me. Looks like a lucky break
considering the depth at which the problem lies.

Thanks for working out all those estimates.

- Marsh