On Mon, 14 Dec 2009 16:40:03 +0100, Martin Rex <mrex@sap.com> wrote:

> Yngve N. Pettersen wrote:
>>
>> A client that does a MCSV-only is almost certainly indicating a version
>> less than its highest supported version, and is either doing that  
>> because
>> it has been forced to fall back to an extensionless Hello (by  
>> intolerance,
>> which rules out an RI capable server, based on my requirements, or by an
>> attacker), or because the client is climbing the version ladder (like
>> Opera), in which case it should try a higher version immediately,  
>> anyway.
>>
>> In combination with my suggestion of directly stating requirements on RI
>> capabable clients and servers about which SSL/TLS version is to be sent  
>> in
>> Client Hellos and serverside version tolerance, the MCSV-only handshake
>> can be used to detect a version rollback attack and counter it by
>> immediately starting to use a Client hello that states highest version.
>
>
> This sound somewhat inconclusive to me.  If it is possible to force
> a client to perform a re-connect fallback, then we can not provide any
> protection against this at the TLS protocol level.  The purpose of MCSV
> is to provide protection from insecure renegotiation between updated
> TLS peers even for fallback-scenarios, so there is nothing that
> needs to be done for the secure TLS renegotiation part.

I am talking about a client, as all current Browser clients, that have to  
allow the use of non-extension handshakes because of interoperability  
reasons.

In that *particular* situation, when it does not know that it is about to  
talk to an RI patched server. Upon discovering that it is indeed RI  
patched, based on my suggestions for requireiement the client knows two  
additional things: 1) It can use the RI extension with this server, and 2)  
it have to make sure that it was not forced to use an older SSL/TLS  
version than it supports. Therefore it should tear down the connection and  
re-establish it, in Opera's case signalling support for TLS 1.2 and using  
the RI extension, and (again assuming my proposal is accepted) the server  
will accept the hello, respond with a RI extension and its highest  
supported version if it is lower than Opera's, and Opera's if the server  
supports a newer version. If the handshake fails in this situation  
somebody is trying to perform a version rollback attack against the client.

>
> Since we are, in fact, suggesting SSLv3 servers to add the renegotiation
> protection patch as well, it would be a flawed assumption that a
> server would select newer protocol features if the client had simply
> sent a more feature-rich ClientHello.  In probabilistic terms, it
> might, but since you are talking about a client that will use a
> feature-rich ClientHello as default and what you described would only
> apply to the fallback scenario, then most of the time this will be
> simply an old server.

The SSL v3 server does not have to select newer protocol features, it just  
have to *tolerate* that the client uses them.

If the server supports renegotiation it will have to implement support for  
the extension, and it have to be flexible enough to handle whatever  
syntactically correct extension list the client sends.

If the server does not support renegotiation then it might not support the  
extension, but my proposal is that it MUST be TLS Extension *tolerant*. I  
am however suggestion, optionally, that supporting the extension should be  
a MUST in patched servers.

> The majority of programmatic clients likely do not have any app-level
> retry logic and neither do they keep lists of servers an the TLS features
> these support in order to optimize their app-level retry logic.
> Usually, those clients just want conservative protocol defaults
> for their ClientHello so that they have a high likelyhood to
> obtain interoperability with most of the installed base.

I am not talking applevel, I am saying that the SSL/TLS implementation  
must restart the connection. The case where that may cause problems, is  
for upgradeable protocols features like SMTP STARTTLS, and I assume that  
all those clients either already have a fallback mechanism that requires  
restart and have an application layer that can handle that, or they signal  
their highest version and uses extension (if they support it) all the  
time, and expect the server to tolerate it.

If it is desirable to avoid restarts, the simple way to handle that is to  
signal highest version and the extension, and require the server to handle  
it.


>> I therefore think it is unlikely that a general purpose client will
>> encounter a server that does not understand the RI extension, and IMO we
>> might just as well make it a requirement that all servers MUST  
>> understand
>> the extension. But I can live with the possibility that the MCSV have to
>> be sent in all initial handshakes, as long as all servers MUST at least  
>> be
>> TLS extension tolerant.
>
> To get rid of complexity, the empty TLS extension RI for ClientHello
> should be completely removed from the specification (i.e. MUST be ignored
> by servers if present).

I disagree. The empty RI should be the default, and the MCSV only used  
when a *lenient* client connects to an *unknown* server, optionally using  
a fallback to a configuration that does not support extensions.

> Implementation-wise it will be even simpler and more robust,
> if MCSV is sent on every renegotiation handshake as well

I am working within the framework of EKR's document.

> (i.e. unconditionally included in all ClientHellos), even when
> there is an accompanying TLS extension RI with  
> Client.Finished.verify_data.

My suggestion does not really touch on that scenario, but my  
recommendation is that the MCSV in only sent in the initial handshake, but  
as long as clients are lenient they may send it in any handshake. Strict  
clients should only use handshakes with the extension, and identifying the  
highest supported version. MVCS should only be used in this case if  
support for the extension is optional in servers that does not support  
renegotiation, but I think that is going to be such a limited amount of  
instances that it is better to require extension support in all servers.

> This will facilitate code that allows backwards interoperable
> renegotiation (server-side).  If either the current session is
> already marked for secure renegotiation or the incoming ClientHello
> carries the MCSV, then the strict rules for secure renegotiation
> processing apply, no matter how willing the server is to perform
> old renegotiation based on its configuration (admin requirement).
>
>
>>
>> The main point of my entire suggestion is that since ALL servers and
>> clients have to be patched anyway, that the RI proposal already makes  
>> (at
>> least) TLS tolerance a requirement, and that many servers are  
>> implemented
>> in a fashion that forces all general clients to behave in an unsecure
>> fashion (automatic version rollback) it would also IMO be a very good  
>> idea
>> to close that security hole at the same time as we close the current  
>> hole,
>> and make it very clear that the version negotiation problem will no  
>> longer
>> be tolerated by RI capable clients.
>
> Some server will not be patched, and for a non-negligable time we will
> have a mix of old and updated peers out there, and every day some more of
> the old will become updated.

My position is that the time for changeover before clients turn strict  
should be no more than 12 months, preferably less.

If we allow a more extendend period for upgrades we can just as well drop  
the current discussion and start working on fixing it in TLS 1.3 instead,  
we won't possibly be able to turn strict before that protocol version is  
widely deployed in year 2020 or 2025.

>> This is an opportunity to close *two* security holes at the same time,  
>> and
>> I think we should take it.
>
> *I* would not refer to the fallback re-try logic in your Browser as
> a security hole.  It definitely does not need to be one, and it's
> completely up to your implementation to ensure that.

It is *impossible* for such fallback code to determine if the server is  
broken or there is an attack going. To interoperate we have had to open a  
security hole, and it is time and more than time to close it permanently.

As it sounds like you may have a way to determine if a connection  
shutdown, no response withing a timout, or a finished message that fails  
is due to a server implementation "mistake", and is not an attack intended  
to force me to use an older version of the protocol, perhaps you can  
provide more details?

> Your idea is an expensive mitigation strategy at best

Expensive? Making sure an if-then-else clause and a variable check is  
correct should not be expensive, nor should fixing it be expensive either.  
The servers have to be fixed anyway.

> (security by obscurity).  If you really wanted to improve that, then
> it might be an idea to signal back to the client the highest supported
> SSL/TLS protocol version of the server along with the currently
> empty TLS extension RI -- and make the initial TLS handshake complete(!)
> (only when the handshake is completed successfully, the information
> exchanged during the TLS handshake is authenticated.

There is already a way for that signal: The client signal its highest  
version, the server selects the lowest of its version and the client's  
stated version, and in RSA also double check this with the version number  
in the RSA Premaster Secret.

There is no need for a more complex signal; we just have to fix the broken  
servers that insist that clients can't use a higher protocol version than  
the one they use.

>> If we don't take this opportunity, we may well have to repeat the "patch
>> all servers" routine again in, at most, a few years.
>
> I don't understand what you are refering to.

What I am saying is that it is conceivable that we could have a break in,  
for example, SSL v3 that makes a live attack on the protocol feasible, but  
only if it can trick the client and server to negotiate a SSL v3.0  
connection, and today that is *trivial*; all major clients do it  
*automatically*! Once that news reach the community there will be a mad  
scramble to disable SSLv3 in servers and clients, and to disable the  
fallback. Let's not wait for that to happen, let's avoid that scramble,  
let's remove the very reason why we need a fallback, at least in strict  
clients and against known RI-patched servers, and let's do it *now*.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************