Re: [TLS] Need for S->C signaling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Michael D'Errico wrote:
> 
> 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.
 
You're correct.  gmt_unix_time was first in that position,
--it should not have to move.

The following should work just as well along with the
magic ciphersuite that indicates this protocol change.

ClientHello.Random =
  {
     uint32        gmt_unix_time;
     uint16        new_protocol_flag_bits;
     uint16        reserved;
     opaque        random_bytes[24];
  }


ServerHello.Random =
  {
     uint32        gmt_unix_time;
     uint16        new_protocol_flag_bits;
     CipherSuite   cipher_suite;
     opaque        random_bytes[24];
  }
     

-Martin



> 
> 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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.