Re: [TLS] [perpass] Let's remove gmt_unix_time from TLS

[[e-mail] (Martin Rex)]

Nick Mathewson wrote:
> 
> My issue here right now that, even *after* taking all these
> precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
> doesn't make it optional.

Huh?  where in rfc6101, rfc2246, rfc4346 or rfc5246 do you find
_anything_at_all_ that could be remotely interpreted as a
requirement for ClientHello.Random.gmt_unix_time to have any
specific value or be within any particular value range -- 
in contradiction to what section 7.4.1.2 says?

(Same for ServerHello.Random.gmt_unix_time).

   http://tools.ietf.org/html/rfc2246#section-7.4.1.2

       Structure of this message:
           The client hello message includes a random structure, which is
           used later in the protocol.

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       gmt_unix_time
       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.


Which part of "Clocks are not required to be set correctly by the
basic TLS protocol" is unclear?  This explicitly spells out that
one can send _ANY_ pattern of 32 bits as gmt_unix_time, as far as
the SSLv3&TLS protocol specifications themselves are concerned.


-Martin