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

[Michael D'Errico <mike-list at pobox.com>]

I agree that something along these lines might be an improvement.
I found it difficult to explain how the upper bit of version is
set, but is not really a version change.

But messing with gmt_unix_time might cause trouble since it's
possible that _something_ out there might rely on it (for what
I have no idea).  So since the bottom few bytes of the random
have no restriction whatsoever, putting the actual cipher suite
there would not break anything.

I'm not convinced that we need a field of flags, though, since
we have TLS extensions.  We should point out in our spec. that
this solution is a HUGE compromise in the quest for backward
compatibility, and that future fixes MAY require extensions.
"You've been warned", etc.

Mike




Martin Rex wrote:
> 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