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

[Michael Gray <[e-mail]>]

[e-mail] 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)
>
>   - 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!

This looks good to me, the only thing I would change is I think MUST NOT
would be better as SHOULD NOT as the later requires that the implementer
examine the conditions and implications etc to make the best decision.  We
know that many current browsers always send extensions and for that use
case there is no need to change due to this specification.  However we also
know that there is a large installed base of SSL consuming applications
that are not browser related that have never had any requirement process
extensions and therefore do not support extensions or are extension
intolerant.


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

We used 177 LoC for a generic parser and another 106 LoC for the RI
specific logic.  However our experience is that additional effort to back
port into unfamiliar old code is far more costly in time than one would
expect based on LoC count even when considering we have current code that
supports extensions.

Additionally a large problem is testing this in code bases that do not
support extensions.  Manual testing can be done, but that is prone to
error, is costly, and time consuming each time we release code, which means
we will need to spend a lot more time developing automated testing.



> Support
> for other TLS extensions and API-level access to TLS extensions
> is completely out-of-scope for the following.

Agree

>
>
> Adding MCSV to ClientHello on the client and parsing MCSV from
> the ClientHello on the server will typically be <10 LoC each.

Agree


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

These are very good numbers and closely match an internal analysis I have
made.


It is likely there will be Servers in critical production environments that
can not be patched (e.g. vendor no longer in business) and they will have
to be fully replaced, as time, planning and evaluation allows (as I noted
here :  http://www.imc.org/ietf-tls/mail-archive/msg11082.html)


I think the fact that Clients may concurrently interact with Servers of
types 5 to 10, means that the MCSV ONLY proposal is the best solution for a
low risk deployment.


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


My guess is that at least five times the effort will be required to add
testing of this into existing auto test harnesses for code levels that do
not support extensions.  Interestingly this vulnerability fix is the only
reason these old code levels now need to support extensions.

Given this large test impact I find the
draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not
require full extension implementation) to be preferable.

- Mick

> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls