Re: [TLS] To extend or not to extend

[Eric Rescorla <[e-mail]>]

At Sun, 15 Nov 2009 03:13:01 -0800,
Joseph Salowey (jsalowey) wrote:
> 
> We need to close on this issue.  To summarize the RI proposal (the draft
> submitted last week) has the following properties in various situations
> 
> 
> A. The RI proposal works fine if both client and server are patched.  
> 
> B. The RI proposal works fine if the client is not patched and the
> server is (the server ends up disabling re-negotiation).  
> 
> C. The RI proposal works fine if the client is patched and the server is
> not, if the server is implemented correctly. 
> 
> D. The RI proposal works fine if the client is patched and the server
> does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if
> they see an extension) and the client desires to implement an secure
> policy and disallows connections to non patched servers
> 
> E. The RI proposal has an issue if the client is patched and the server
> does not implement the SSL 3.0 and the TLS 1.x specs correctly and the
> client as a lenient policy which allows connection to insecure servers.
> In this case the client would have to implement some fallback logic
> (reconnect without extensions) to deal with broken servers.  This logic
> is well-known, but it leaves a roll-back attack open.  This can be
> plugged by using the proposed ciphersuite signal only in the case where
> extensions cause a handshake or connection failure.  The fallback
> cipher-suite signaling for RI to prevent rollback extends TLS in an
> unexpected way, but this is limited only to the case where we have to
> deal with broken implementations.  

So, thinking further on my earlier message, I think the following 
elaboration will work a bit better:

- Strict clients (those which wish to insist on RI) generate RI on
  initial handshake. As I said earlier, I don't think this is
  useful, but it works.

- Lenient clients do not generate RI on initial handshake but do
  generate it on rehandshake with TLS 1.0+ only. 
  + Moderately lenient clients can fail if the server does not
    do RI.
  + Really lenient clients can ignore the server's failure to
    do RI.


This has the following advantages:
For all non-renegotiated settings you get exactly the same interop
properties you ordinarily would. I.e., it just works. With
renegotiation, you get an extremely high interop probability even if
the server has not upgraded because compliant TLS implementations are
required to at worst ignore extensions (RFC 2246; S 7.4.1.2), and
you've already weeded out SSLv3-only implementations in the initial
handshake.

Now, there is still arguably a downgrade attack because the attacker
can simulate a completely broken SSLv3 stack and force you down to
SSLv3 in the initial handshake (they can't do it in later handshakes
because those are protected). Note, however, that since we're not 
exercising the extension logic in that handshake (though of course
the client may be exercising it for some other reason, say if it's
doing SNI), the server the attacker is simulating has to be really broken
because it's not handling version number negotiation correctly. However,
we can still use a cipher suite indicator if we think it's absolutely
necessary to allow fallback to SSLv3 here.

-Ekr