Re: [TLS] Protected Renegotiation -- refined proposal

[Eric Rescorla <[e-mail]>]

Martin,

I agree that these have similar properties cryptographically,
but I don't agree that it is really an improvement overall.

As I understand your proposal, the advantage that it offers
over RI is that with RI an attacker can simulate an extension
processing failure. This leaves the client unable to distinguish
between:

- A server which does not support RI (and therefore is potentially
  though not definitely vulnerable to a renegotiation attack)
- An attacker who is blocking RI.

By contrast, with your proposal the client can reliably distinguish
these two, because additional unknown ciphersuites do not cause
failures. I have two observations about this:

1. I'm not sure that differentiating these two cases is that 
   interesting.

   - For the foreseeable future, the majority of servers will
     not support RI, so clients can't really do anything useful
     with the information that the server doesn't support it.
     Remember that implementations which DO support RI really
     should not be allowing renegotiation without it, in
     which case if a client is fooled into thinking that
     the server doesn't do RI, the likely result is that
     the client can't renegotiate, not an unsafe renegotiation
   - Non-support of RI is not necessarily an indicator of 
     vulnerability since many servers will simply patch 
     to the point where they don't renegotiate but not add
     RI support.
   - Any implementation of SSL/TLS which is so downrev that it
     cannot properly process extensions most likely has other
     serious security vulnerabilities so a client which wishes
     to be careful and not deal with servers which don't support
     RI should probably not connect to it in any case. IOW,
     the attacker can just force a paranoid client not to
     connect at all.

2. If you're interested in differentiating these cases in an
   unspoofable way, there's a compromise method which doesn't require
   a covert version upgrade that is signalled by the client in the
   cipher suite but not in the version number (contrary to the
   ordinary TLS style).

   Under ordinary conditions you offer TLS as usual with RI. If
   you get an error and are forced to fall back to SSLv3 or
   otherwise remove RI, *then* you signal an additional fake
   cipher suite whose only semantics are:
   "I tried to do RI but I was forced to downgrade." Servers
   which support RI can then simply generate an error if they
   ever see this cipher suite. [Alternately, you could always
   include the cipher suite, which makes the client logic
   simpler and the server logic slightly more complicated
   because the error becomes conditional.]

   This design has the advantage that it retains the ordinary
   TLS extension mechanism as the "main" code path and only
   uses the fake cipher suite as a fallback to detect inline
   downgrade. This is very much in the spirit of the existing
   TLS belt-and-suspenders defenses (e.g., the 030303... padding
   in the RSA when downgraded to SSL version 2). It also doesn't
   screw up our versioning scheme if/when we want to do 
   TLS 1.3. As far as I can tell, the major disadvantage 
   vis-a-vis the scheme you propose is that it requires one
   more pass with servers which don't support extensions, 
   but IMO given that modern browsers now offer SNI, we're
   beyond the point where we have to be afraid of routinely
   offering extensions and falling back if necessary.

-Ekr

   


      



   
     
     
 









At Fri, 13 Nov 2009 16:34:59 +0100 (MET),
Martin Rex wrote:
> Nico an I are talking about slighty different things.
> 
> I will try to reexplain my most recent mind model of how this should
> be solved, and you will see that the cryptographic properties are
> almost identical to the TLS extension RI.  My most recent model
> will actually grow naturally into TLS v1.3 and become invisible.
>
> The cryptographic concept behind the actual fix:
> 
> I. Initial SSL/TLS Handshake on a connection
> 
>     Here we want to achieve three things:
> 
>      a) Securely signal from client to server that client is updated
>      b) Securely signal from server to client that server is updated
>         (provided that client has indicated that it will understand
>          this information)
>      c) Signal that this is an initial handshake so that it can not
>         be proxied into a renegotiation handshake
> 
>    in an abstract fashion, the protocol update looks like this:
> 
>    Initial SSL/TLS handshake on a connection
> 
>        Traditional:         Updated:
> 
>        ClientHello          ClientHello + ProtocolUpdateIndicatorC2S
>        ServerHello          ServerHello + ProtocolUpdateIndicatorS2C
>            -- all further handshake messages unchanged ---
> 
>     TLS extension RI:
> 
>        (1a) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorC2S
>        is a ClientHelloExtension "RI" with empty data
> 
>        (1b) + (1c) For the TLS extension RI, the ProtocolUpdateIndicatorS2C
>        is a ServerHelloExtension "RI" with empty data
> 
>        Both ProtocolUpdateIndicators have no special cryptographic
>        properties.  They're part of the handshake messages so that
>        can not be stripped from an MITM without breaking the
>        MAC-check by the Finished messages.
> 
>     My (revised) proposal:
> 
>        My proposal is to use two other ProtocolUpdateIndicators
>        instead that can be added to all existing protocol versions
>        with significantly less pain an suffering, and in a fully fowards
>        compatible fashion so that this ProtocolUpdate will grow out
>        naturally with the next TLS protocol update (TLSv1.3)
> 
>        (1a) assign a special ciphersuites ID as ProtocolUpdateIndicatorC2S
>        that is to be included in the ciphersuites list of the ClientHello
>        and extremely backwards compatible with installed base servers
>        that implement SSLv3->TLSv1.2  (0x03,0x00) -> (0x03,0x03).
> 
>        (1c) change the computation of the finished mac for all renegotiation
>        handshakes
> 
>        (1b) increase the major number of the protocol version by one as the
>        ProtocolUpdateIndicatorS2C, which means:
> 
>           0x03,0x00  SSLv3, unpatched        0x04,0x00  SSLv3 patched
>           0x03,0x01  TLSv1.0, unpatched      0x04,0x01  TLSv1.0 patched
>           0x03,0x02  TLSv1.1, unpatched      0x04,0x02  TLSv1.1 patched
>           0x03,0x03  TLSv1.2, unpatched      0x04,0x03  TLSv1.2 patched
> 
>           (0x03,0x04  TLSv1.3 only for client_version)
>                                              0x04,0x04  TLSv1.3
> 
>        (1a2) A client that sends a ClientHello with a client_version
>              that is >=0x03,0x04 also indicates that it will used the
>              changed computation of finished mac calculation for
>              the renegotiation handshake.
> 
> 
> II. Renegotiation SSL/TLS handshake on a connection
> 
>     Here we want to achieve:
> 
>        a) cryptographic binding of the renegotiation handshake to the
>           previous session by adding the verify_data of the previous
>           finished messages as known to the client into the handshake
>           message hash (->ClientVerify, ->Finished)
> 
>        b) cryptographic binding of the renegotiation handshake to the
>           previous session by adding the verify_data of the previous
>           finished messages as known to the server into the handshake
>           message hash (->ClientVerify, ->Finished)
> 
> 
>     Renegotiation SSL/TLS handshake on a connection
> 
>        Traditional:         Updated:
> 
>        ClientHello          ClientHello + ClientsPreviousVerifyData
>        ServerHello          ServerHello + ServersPreviousVerifyData
>            -- all further handshake messages unchanged ---
> 
>     TLS extension RI:
> 
>        (2a) adds the clients verify_data from previous client.finished
>             message into ClientHelloExtension RI
> 
>        (2b) adds the servers verify_data from previous (client.finished and)
>             server.finished message into ServerHelloExtension RI
> 
>        The Handshake Messages MAC will roughly receive the following data:
> 
>          ClientHello
>          FF 01 00 01 0C
>          <verify_data of client's previous client.finished>
>          ServerHello
>          FF 01 00 01 18
>          <verify_data of server's previous client.finished>
>          <verify_data of server's previous server.finished>
>          -- all further handshake messages unchanged ---
> 
> 
>     My (revised) proposal:
> 
>       (2a)+(2b) effectively change the computation of the finished macs
>         by redefining what goes into the handshake message hash if the
>         updated protocol is used.  The verify_data of the previous
>         client.finished and server.finished messages are defined to
>         be handshake messages that are _not_ sent in the current
>         handshake (think of it as carryover from the previous handshake).
> 
>        The Handshake Messages MAC will roughly receive the following data:
> 
>       Client-side:
> 
>        ClientHello
>        ServerHello
<>        <verify_data of client's previous client.finished>
>        <verify_data of client's previous server.finished>
>        -- all further handshake messages unchanged ---
>      
>       Server-side:
> 
>        ClientHello
>        ServerHello
>        <verify_data of server's previous client.finished>
>        <verify_data of server's previous server.finished>
>        -- all further handshake messages unchanged ---
> 
>       The verify_data should become a "virtual handshake message"
>       _after_ the ServerHello, when client and server both know
>       that they're really using the updated protocol.
> 
>       To me, it looks like this approach and TLS extension RI are
>       very similar in their cryptographic properties.
> 
>       By adding the verify_data to the handshake message MACs (but
>       not the message stream) always after ServerHello, they are also
<>       covered by the clients signature in the ClientVerify message --
>       in case that cert-based SSL/TLS client authentication is used.
>       This property is also similar to TLS extension RI.
> 
>       If the clients memories about the previous session differ from
>       those of the server, the finished messages of the renegotiation
>       handshake will differ.  If client cert authentication is used,
>       the signature verification of ClientVerify will already fail.
> 
> 
> 
> -Martin