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

[Martin Rex <[e-mail]>]

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)

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

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


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

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

  - 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
     - MUST be sent in all other 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.

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.


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.


Types of TLS peers in the current installed base:

1.)  old TLS client, no extensions, no renegotiation

2.)  old TLS client, no extensions,    renegotiation

3.)  old TLS client,    extensions, no renegotiation

4.)  old TLS client,    extensions,    renegotiation


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

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

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

8.)  old TLS server, no extensions,            renegotiation 

9.)  old TLS server, extensions,            no renegotiation

10.) old TLS server, extensions,               renegotiation


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

Additional types of TLS peers when TLS extension RI is implemented:

11.) updated TLS client, RI-minimal,    no renegotiation

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


  
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




-Martin