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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf