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

> Yngve N. Pettersen wrote:
>>
>> I also think that a client supporting RI which, due to fallback
>> negotiation procedures, sent a MCSV-only handshake MUST, upon  
>> discovering
>> that the server supports RI, terminate the connection (with a warning
>> close notify, since it is not a real error), and re-establish the
>> connection with a Client Hello that uses the RI extension.
>
> I'm sorry, but I think that is a particularly bad idea, and completely
> unnecessary.  In the IETF we are supposed to define and/or extend
> protocols in a fashion that promotes interoperability.

Please note my pre-requisite for this suggestion: That the server MUST be  
Extension tolerant (preferably extension understanding, but that is beside  
the point in this case), and that this suggestion is mostly intended to be  
used in combination with the second requirement of my proposal: Version  
tolerance. As I said, "The reason for this will become clear below."

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.

>> If this is implemented, this means that all patched servers will be TLS
>> Extension tolerant, even if the only extension they understand is the RI
>> Extension.
>
> There is a misunderstanding about the term "Extension tolerant".
> That is supposed to characterize the ClientHello forward compatibility
> in the 18-Nov-1996 SSLv3 document, in TLSv1.0 (rfc-2246) and
> TLSv1.1 (rfc-4346).  It means that the server receiving data after
> compression_methods in ClientHello will tolerate the presence of
> this data, but otherwise _completely_ ignore it.

Maybe I should have said "understands TLS Extensions", but that is only a  
requirement in my proposal if MCSV is optional in an RI-hello, and my  
understanding of the *current* text in -01 is that the MCSV *is* optional  
when the RI is sent. My suggestion is to clearly enumerate the cases where  
it is required, and when a client MAY send it.

However, I think that there is going to be very few (if any) cases where a  
server vendor knows in advance that the server is never going to do  
renegotiation and is never going to accept it. In those cases I also  
suspect that the vendor is also in control of the client software, and in  
such special cases a vendor can probably do whatever they want.

In just about all other cases we will be talking about general purpose  
servers where it is at least conceivable that they will have to complete a  
renegotiation in some deployments, and in those cases the server MUST  
understand the RI extension, also in the initial handshake.

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.



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.

This is an opportunity to close *two* security holes at the same time, and  
I think we should take it.

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 think that is an  
expensive way to save a few hours of checking that a few lines of code are  
actually doing what they should have been doing the past 15 years, and if  
necessary fix them.


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