Re: [TLS] Proposal for hybrid solution using most of the ideas

[Martin Rex <mrex at sap.com>]

Chris Newman wrote:
> 
> --On November 19, 2009 22:23:43 +0100 Martin Rex <mrex at sap.com> wrote:
> > Asking SSLv3 implementations to improve on their extensions-intolerance
> > is still OK.  Requiring them to implement generic TLS extensions
> > is not, because it has nothing to do with the problem and is
> > an unnecessary complexity for the fix.
> 
> What if we require SSLv3 compatible clientHello and SSLv3 serverHello to 
> list RI first and at least ignore additional extensions, waiving the 
> requirement for full extension support for SSLv3-only implementations?

I don't see how this would solve the problem.

How to you interoperate with installed base SSLv3 and TLSv1.0 that
is extensions-intolerant without being vulnerable to downgrade attacks?

The restriction that this extension must be first comes very unnatural
and is bound to result in interop problems, because it will usually
not show up in tests that have generic TLS extension functionality.
It seems like dangerous design.


Maybe this explains the abstract problem better:

If you look at the two different possibilities to get the verify_data
into the handshake message hash on renegotiation:

   1)  put them into a handshake message and they will be hashed
       automatically

   2)  have each peer add them manually to the handshake message
       hash directly after ServerHello
 
which of the two is better engineering-wise?

Definitely (2).  (1) is incomplete and fails unsafe.

It is unlikely that if (2) was used that _everyone_ would implement
it incorrectly.  If implemented incorrectly, you will get interop
problems when testing with regular old and new peers.
So this approach fails safe.


No matter how poorly you implement (1), you will always interoperate.
What is missing in (1) is the requirement, that the verify_data in
the handshake messages is actually verified by the receiver!
If you have implementors that actually forget to perform
the comparison, you will NEVER notice this in interop-tests.
You will actually need to build yourself attack-tools to make
sure that your implementations actually verify that data.
So approach (2) fails UNsafe. 


It is true that I did add (2) to my last proposal by including
the verify_data in the Hello.Random elements.  *I* still prefer
to call the hash function manually, because it will fail safe.


-Martin