Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]