Re: [TLS] Need for S->C signaling

[Martin Rex <mrex at sap.com>]

Actually we could use your idea for a more symmetric signaling!

Stephen, I REALLY like this idea!


Since there are people that didn't like the gmt_unix_time
in Random anyway, we could just re-purpose it entirely.

Add a single magic ciphersuite as first(!) in ClientHello.cipher_suites
and then the field "ClientRandom.gmt_unix_time" must be interpreted

  ClientHello.Random =
    {
      uint16   field_of_flags
      uint16   reserved
      opaque   random_bytes[28]
    }

  And when the server sees that magic cipher suite and implements
  this protocol extension, then it will return the magic cipher suite
  as negotiated ServerHello.cipher_suite and then the definition
  of the ServerHello.Random will be this:

  ServerHello.Random =
   {
     uint16       field_of_flags
     CipherSuite  cipher_suite      /* real negotiated cipher_suite */
     opaque       random_bytes[28]
   }
   
Those implementors who want to keep a gmt_unix_time in their Random
to provide uniqueness, will need to put it somewhere into random_bytes,
like in the first 4 octets of that element.


This would give us 16 free bits for bi-directional signaling in
ClientHello and ServerHello at the cost of 2 Bytes in ClientHello.

The fun part: these bit-flags are not only protected by the
handshake message hash, they actually go into the PRF for
the session keys.  Some kind of extra protection.  :)


-Martin

PS: the session ID is used by servers to manage their cache
    and may also be used by server-side load-balancers.
    the session ID is only "random"-equivalent for the client