Re: [TLS] Server time

[Jeffrey Walton <[e-mail]>]

> Consensus was to drop time from the random fields. Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. (note that ServerHello is already changed by dropping compression_method)
>
+1. Random should be random. Placing time in the random field meant
the field was not used for its intended purpose. It violated the
engineering design. (Whether it resulted in a vulnerability is a
different debate).

> The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost.
>
+1. Some Android phones have a peculiarity where they will fail their
very first path validation (like after a factory reset). The phones
don't have a SIM and use Wifi. We think its because of the clock (we
have never been able to duplicate it, but I've seen the field
reports).

Other older phones have the same issue, but its persistent. That is,
the phone won't set the time if there's no network. You have to SIM
the phone or manually set the time.

I think the same problem will arise in the future with the Internet of
Things. Refrigerators and thermostats will experience similar issues.
History has a tendency to repeat itself.

The time field begs the question: what is the presentation of time? Is
it a UTC or GMT time? Is it a local time? Is there time zone data
associated with it?