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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
