Re: [TLS] TLSrenego - current summary of semantics and possibilities

[<[e-mail]>]

Martin,

I think we should provide *some* way to make this secure while still
allowing "fallback to less advanced TLS handshakes" (e.g. from "TLS
1.2 with extensions" to "TLS 1.0 without any extensions", or even
"SSLv3 without any extensions" -- the specifics vary from one
implementation to another, but I think "without extensions" is
one common part). Those fallbacks aren't going to go away any time 
soon...

Of the possibilities listed in your email, my preference would to
allocate a cipher suite number that means "I support the renegotiation
extension, but chose not to include it" (perhaps because an earlier
connection with the extensions failed -- which could have been caused
by the attacker).

(If I recall right, some tests I run around 2006 suggested that
some servers didn't like ClientHello's proposing non-NULL compression
algorithms -- so a magic compression algorithm number might lead
to interop problems, too. But AFAIK all servers properly ignore 
cipher suite numbers they don't support...)

Best regards,
Pasi
(speaking as individual contributor, not wearing any hats) 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> ext Martin Rex
> Sent: 10 November, 2009 21:28
> To: Michael D'Errico
> Cc: [e-mail]
> Subject: [TLS] TLSrenego - current summary of semantics and
> possibilities
> 
> Michael D'Errico wrote:
> >
> > A client that wants protection from this attack MUST send the
> extension
> > in its initial handshake.  Why don't you want to do that?
> 
> If there were only well-behaved servers out there, there would not
> be any problem.
> 
> The default configuration of MSIE6 on WinXP to disable TLSv1.0, as well
> as newer browsers providing a reconnect fallback to SSLv3-only
> ClientHello
> indicate that there is an installed base of TLS servers that either
> predates the SSLv3 internet-draft from Nov,18th 1996 or is defective.
> 
> There used to be a draft draft-pettersen-tls-interop-experience-xx.txt
> (I have archived a -00 that expired oct-2006), which describes the
> mess around spec non-compliance.  TLS-extensions are covered in section
> 4.
> 
> What it seems to indicate, in essence, is that the for maximum
> interoperability with the installed base of (broken) servers out there,
> you use a SSLv3 ClientHello with (0x03,0x00) in the client.version
> and _no_ TLS extensions.
> 
> So conservative clients that do not want to implement reconnect
> fallbacks may have a problem with the recommendation to always
> use a TLS extension.
> 
> 
> 
> There are a number of things we would like to achieve with a fix:
> 
>   - provide a method for secure renegotiation in the future
> 
>   - deprecate the traditional renegotiation
> 
>   - provide a secure base for the (previously flawed) assumptions
>     of servers when performing a renegotiation to request a
>     client certificate.
> 
> 
> in oder to achieve this, we should probably make the following
> recommendations:
> 
>   - if a TLS client (any protocol version, including SSLv3) performs
>     renegotiation (i.e. sends a ClientHello over an established
>     TLS session with a ciphersuite other than TLS_NULL_WITH_NULL_NULL),
>     then it SHOULD always and unconditionally use the TLS extension
>     Renegotiation_Info containing the verify_data of the
> client.finished
>     handshake message from the active TLS session,
>     The TLS client should do that even when it did not send the
>     TLS extension Renegotiation_Info with and empty extension data
>     in the initial TLS handshake on a connection!
> 
>     Lacking application level re-connect provisions for forward-
> incompatible
>     SSL/TLS servers, a TLS client might not want to sent the TLS
> extension
>     in the initial ClientHello of a connection.
> 
>     If the presence of the TLS extension Renegotiation_Info causes the
>     server to abort the TLS connection, then that
>     server is not capable of secure renegotiation, and the TLS client
>     should abort the Handshake with an error and close the connection
>     in order to protect the client and the clients credential from
>     abuse with servers that are still vulnerable to the TLS
>     renegotiation problem.
> 
>  -  A TLS server (any protocol version, including SSLv3) should require
>     the presence of a TLS extension Renegotiation_Info for _every_
>     renegotiation handshake.
> 
>     If the TLS extension Renegotiation_Info is absent from the
> ClientHello
>     received on an active TLS session, the server should abort the
>     connection. (add Alert here)
> 
>     If the TLS extension Renegotiation_Info is present, then the TLS
> server
>     MUST verify the contained verify_data of the client.finished
> message
>     as known to the client with its own memorized client.finished
>     message from the SecurityParameters of the current TLS connection
> state.
> 
>     If the comparison of the verify_data from the client.finished
>     messages fails, the server MUST abort the connection.
> 
>     When the client's and the server's notion of the verify_data from
>     the previous TLS session compare equal, the server MUST send back
>     the TLS extension RenegotiationInfo with in a ServerHelloExtension
>     containing the verify_data from the client.finished message and
>     the verify_data from the server.finished message.
> 
>  -  A TLS client (any protocol version, including SSLv3) that receives
>     the TLS extension Renegotiation_Info in a ServerHello extension
>     must compare the extension data with its own SecurityParameters
>     in the TLS connection state.
> 
>     If the Renegotiation_Info with empty extension_data is received
>     on a client's initial TLS handshake, everything is fine
> 
>     If the Renegotiation_Info with empty extension_data is received
>     on an active TLS session, the client MUST abort the handshake
>     with an error and close the connection.
> 
>     If the Renegotiation_Info with non-empty extension_data is received
>     on a client's initial TLS handshake, the client MUST abort the
> handshake
>     with an error and close the connection.
> 
>     If the Renegotiation_Info with non-empty extension_data is received
>     on a client's renegotiation handshake, the client MUST compare the
>     contained verify_data of the server-memorized client.finished and
>     server.finished messages with its own memorized verify_data for
>     both finished messages in the SecurityParameters of the TLS
> connection
>     state for the current session.
>       - if they compare equal, everything is fine
>       - if they do not match, the client MUST abort the handshake and
>         close the connection.
> 
> 
> 
> It is possible that a TLS client may not want to assert the TLS
> extension
> Renegotiation_Info in an initial ClientHello because of
> interoperability
> concerns with an installed base of not-quite-spec-compliant servers.
> 
> What other strategies could be used on the initial handshake on a
> connection with lesser side effects that a TLS extension
> Renegotiation_Info
> with empty extension_data?
> 
> 
> Overloading ("abusing") the semantics of other regular elements
> of an SSL/TLS handshake that have a lesser likelihood to upset
> legacy servers.
> 
>    - Assign one (or two) specific ciphersuite IDs that the client
>      can include in the ciphersuites list which signal the clients
>      notion of the connection state (initial vs. renegotiation)
>      to the server.
> 
>    - Assign one (or two) compression algorithm IDs that the client
>      can include in the supported compression algorithms list which
>      signal the clients notion of the connection state (initial vs.
>      renegotiation) to the server.
> 
> I assume that a Client->Server signalling through a special cipher
> suite
> might be the easy to implement for clients and expect that it has the
> least side effects on handshakes with old servers.
> 
> Fancy compression algs might be less digestable to old servers.
> 
> 
> Both of these (one or two fany ciphersuites in the ciphersuite
> list of the client) can only be used for signalling from client
> to server, not in the direction server to client.
> 
> 
> What could be used to signal from the server to the client that the
> client should send the TLS extension Renegotiation_Info in the
> ClientHello of a renegotiation handshake if the client does not
> want to send the TLS extension in the initial handshake of a
> connection?
> 
> We could define a new TLS handshake message "RenegotiationRequest"
> to be sent instead of a "HelloRequest".  This would be an option for
> those servers, that will abort the handshake and connection
> if the client does not send the TLS extension Renegotiation_Info.
> 
> The purpose of a RenegotiationRequest would be to encourage clients to
> send the TLS extension Renegotiation_Info, in order to keep existing
> usage scenarios usable.  The message itself is not protected, but
> that doesn't matter.  The servers decision for success or failure
> of the renegotiation depends only and entirely on the use of
> the TLS extension Renegotiation_Info in the renegotiation handshake
> and successful verification of the verify_data from the
> client.finished handshake message of the active TLS session.
> 
> 
> 
> -Martin
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls