[TLS] Protected Renegotiation -- refined proposal

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> Nicolas Williams wrote:
> > 
> > The whole point of my post was to point out that there is a way to do
> > the server->client signaling without changing a single bit on the wire
> > -- just the Finished message computations.
> > 
> > Interestingly, that approach could even be used on initial connections
> > to detect if the server will support secure re-negotiation _before_ the
> > client ever tries it.
> 
> I don't see that. AFAICT both your options involve the client generating a 
> hello extension, so this does affect the bits on the wire. Obviously
> there are approaches which don't require that, but they don't provide
> detection of server capabilities on initial negotiation. By contrast
> your message of 1854 doesn't allow the client to probe the server 
> AFAICT.


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