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.