Chris Newman wrote:
Evaluation relative to draft-mrex-tls-secure-renegotiation-03:
Kudos to Martin Rex for producing such a good alternate proposal. The
introductory text up to and including section 4.1 is very good and would
improve draft-ietf-tls-renegotiation. While I would support a consensus to
publish the mrex document as the solution, I presently prefer
draft-ietf-tls-renegotiation-01 for four reasons:
1. Running code: multiple implementations and interop testing was performed
on an earlier version of draft-ietf-tls-renegotiation.
I have published a diff for OpenSSL-0.9.8l that implements
draft-mrex-tls-secure-renegotiation-03.txt.
ftp://ftp.sap.com/pub/ietf-work/tls/
It amounts to ~120 Lines-of-Code (180 if you include empty lines and braces).
It is less than half the code footprint of the TLS extension RI
that is contained in openssl-0.9.8-stable-SNAP-20091205,
(and that TLS extension RI implementation is based on an earlier
proposal, doesn't have the MCSV yet, so lacks support for SSLv3
SSLv2 ClientHellos, conservative clients and reconnect fallbacks
and protection from downgrade attacks.)
So if you're in a hurry, here is a document in better shape,
an implementation in better shape, which requires less code
changes -- in particular for old implementations that do not
contain TLS extensions (how to implement S->C signaling with
no TLS extensions coding is part of my patch for OpenSSL and ~20 LoC).
As has been previously discussed, there are very few code paths
and a failSAFE design, so this approach is _much_ easier to test
than TLS extension RI.
2. Impact to core protocol handshake: The mrex proposal alters the
handshake to include data that is not exchanged in-protocol.
My proposal does not "alter" the handshake. It just defines extra
handshake messages that are _NOT_ transferred over the network
(since both peers already have it, there is no need to acutally
send them).
The point being the mrex proposal requires more analysis
to verify impact. As we're in a hurry, I prefer to easier to analyze
proposal.
I don't see a need for further analysis. I put more thought on this
one now than I put into finding the TLS renegotiation vulnerability,
so by now I pretty sure it is as sound, safe and secure as the
rest of the TLS handshake design. There are _no_ new concepts.
3. Extensibility. In my experience one of the protocol design features
most important to get right is extensibility. SSL/TLS didn't really
get that right until v1.2 (which is causing problems now).
As draft-ietf-tls-renegotiation uses the TLS extension
facility more extensively, it will help future-proof more
implementations.
It doesn't simply "use", draft-ietf-tls-renegotiation will _require_ it
back to 1995 and be quite hostile about interop with the installed base
If you want an example for "use" of TLS extension in a non-offending fashion,
draft-mrex-tls-secure-renegotiation-03 "uses" TLS extensions.
4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST
in some circumstances. That approach is untested in the field
This claim is quite unsubstantiated.
My proposal requires TLS_RENEGO_PROTECTION_REQUEST, but adding new
ciphersuites is something that has been done many times before quite
successfully. The AES ciphersuites (rfc3268,June 2002) came before
TLS extensions and didn't remotely cause any of the interop problems which
TLS extensions were found to cause.
Today, Firefox 3.0 will send Camellia ciphersuites in a SSLv2 ClientHello.
There is fairly broad consensus in the TLS WG that the extensibility
of the cipher_suites field in ClientHello has by far the least number
of interop problems in the TLS protocol.
Severe interop problems are known for TLS protocol versions and
presence of TLS extensions.
* There may not be a sufficient number of "extension intolerant" SSL/TLS
servers in operation to justify the added complexity of
TLS_RENEGO_PROTECTION_REQUEST. However, I do not object to inclusion as
it's possibly helpful for some alleged extension intolerant servers
compliant with early drafts of SSLv3 and it helped move closer to WG
consensus.
The Complexity of TLS_RENEGO_PROTECTION_REQUEST is a magnitude smaller
than that of a TLS extension RI in the initial ClientHello (and in
renegotiation ClientHellos during backwards interop with old servers).
You can see from the OpenSSL diff I provided above, just how much
smaller and easier to implement the MCSV is compared to TLS extension RI.
* Non-extension signaling for ServerHello: I am strongly opposed to using
any mechanism other than TLS extensions for signaling in the ServerHello.
I found all such proposals (including overloading the version field) far
too risky. As the earlier mrex draft proposing such mechanisms was
replaced by a revision which now uses the extension mechanism, I believe
the matter is settled.
Thanks. I said from the beginning that I'm open to suggestions
for the Server->Client signaling. And I adopted the solution from
draft-ietf-tls-renegotiation-01.txt after it had been added there.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf