Re: [TLS] Server time

[Jeffrey Walton <[e-mail]>]

> Keep in mind that we removed the time from the Hello random fields
> because they leaked information that made it easier to track clients.

Tracking and anonymity has a different solution. I don't understand
how folks can claim they are solving this when the first TCP SYN
usually begins the tracking process. What happens after the TCP stream
begins is irrelevant.

> And note that clients often play the server roll in (D)TLS. In
> particular, clients act as both the client and server in DTLS for
> WebRTC. Consequently, there always needs to be a way for the server to
> NOT say what time it thinks it is.

In this case, allow a value of 0. In RFC 1952 (GZIP file format
specification), a MTIME of 0 means no time is available.

On Sun, Apr 5, 2015 at 2:11 PM, Brian Smith <[e-mail]> wrote:
> Dave Garrett <[e-mail]> wrote:
>> Consensus was to drop time from the random fields.
>
> Right.
>
>> Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution.
>
> What problem does it solve?
>
>> (note that ServerHello is already changed by dropping compression_method)
>
> That seems unnecessary to me. compression_method could/should just be
> fixed to be "null", avoiding unnecessary compatibility risk.
>
>> The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost.
>
> The client can sanity check or sync its time using other mechanisms
> already, even with earlier versions of TLS. I don't see how adding a
> time field to ServerHello would help solve that problem.
>
> There may be occasions when the server and client need to sync time,
> e.g. if it helps the 0-RTT handshake in some way. But, that should be
> done as part of the specification for whatever mechanisms require it.
> See the long-ago discussion about this [0].
>
> Keep in mind that we removed the time from the Hello random fields
> because they leaked information that made it easier to track clients.
> And note that clients often play the server roll in (D)TLS. In
> particular, clients act as both the client and server in DTLS for
> WebRTC. Consequently, there always needs to be a way for the server to
> NOT say what time it thinks it is.
>
> Cheers,
> Brian
>
> [0] https://www.ietf.org/mail-archive/web/tls/current/msg10861.html