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

+1

In environments where you already do a lot of implementation tricks to save
code any LoC saving is more than welcome. We have two SSL/TLS
libraries, one for J2SE (Java Standard Edition) and one (client-side) for
J2ME (Java Micro Edition). Whereas the J2SE version supports TLS extensions,
the J2ME version does not (not requested so far). One major goal of our J2ME
edition was (and is) to keep its size as small as possible (because this is 
the
main concern of our customers).
After implementing and comparing both alternative fixes
(for our J2SE library), we would prefer draft-mrex-tls-secure-renegotiation
(smaller code size increase, less bandwidth, easier to integrate into SSL
and extension-less TLS implementations, therefore less error prone,
less test amount and faster deployment).

- Dieter



----- Original Message ----- 
From: "Michael Gray" <mickgray@au1.ibm.com>
To: <mrex@sap.com>
Cc: <tls@ietf.org>
Sent: Thursday, December 10, 2009 3:16 AM
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV


>
> mrex@sap.com 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls