Re: [TLS] Proposal for hybrid solution using most of the ideas
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Marsh Ray wrote:
> 
> Stefan Santesson wrote:
> > 
> > What I don't understand is the rationale for providing two solutions, when
> > one solution could work for all cases.
> 
> TLS can support a nice, clean, efficient solution going forward.
> 
> SSLv3 needs an ugly dirty hack, no way around it.

I'm sorry but you are mis-representing the facts in an unfair fashion.

Both approaches, TLS extension RI and my extension-free solution
change the existing protocol in the _exact_ same fashion from
an abstract point of view:

 -  both approaches add the verify_data of Client.Finished and
    Server.Finished into the handshake message hash directly
    after the ServerHello handshake message for renegotiation
    handshakes

 -  both approaches use the ClientHello and the ServerHello
    for signaling/negotiation


The changes only materialize in different bits-on-the-wire
and use a slightly different sequence of API calls to
achieve this.

The extension-less approach is going to be applicable to all existing
usage scenarios (even the SSLv2-compatible ClientHello I think)
and does not change the bits-on-the-wire of the renegotiation
handshake at all adds a ciphersuite ID to ClientHello and
re-purposes a single bit in the ServerHello -- it is difficult
to conceive to make this any more conservative.  The code changes
required for the extension-less approach is extremely small,
non-ambiguous and almost trivial to test for interoperability.


obvious problems of TLS extension RI:

 - adds significantly more bits-on-the-wire to initial and
   renegotiation handshakes

 - modifies the initial and renegotiation handshakes in different ways

 - is NON-interoperable with a significant amount of the installed
   base of SSLv3 _AND_ TLSv1.0 servers

 - can NOT be used in apps-level extension-less ClientHello fallbacks
   as implemented in most current Browsers

 - is vulnerable to downgrade attacks because of its incompatibilty
   with apps-level extension-less ClientHello fallback

 - can NOT be used in conservative clients that do not contain
   an apps-level extension-less ClientHello fallback

 - requires more code changes to implement than extension-less
   approach in newer codelines

 - requires _significantly_ more code changes to implement than
   extension-less approach in older codelines without TLS extensions

 - clients and servers that do not implement renegotiation at all
   need the full amount of code changes

 - significantly more complex test-scenarios, development of
   interop test tools required for reliable interop-testing,
   even for implementations that do NOT contain renegotiation.


-Martin

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.