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

[Brian Smith <[e-mail]>]

On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang <[e-mail]> wrote:
> PROPOSAL 4:
>
> Add a random clock skew to the current time. For example, generate a
> random signed integer in the interval [-512, 511] (inclusive) and add
> it to the return value of time(). This adds roughly a +/-8.5 minutes
> skew to the current time.

When the server tells the client that it supports the 0-RTT handshake
scheme, can't the server also tell the client what time the server
things it is? Then the client could calculate the offset between its
local perception of the time and the server's perception of the time,
and apply that offset to whatever timestamp it sends in its 0-RTT
handshake.

Also, timestamps is only needed for the 0-RTT handshake, handshakes
that aren't attempting to be 0-RTT shouldn't include a timestamp. So,
the timestamps should probably be moved to the extension that
negotiates the 0-RTT handshake. That way, the fingerprinting risk,
whatever it is, is limited to applications that are actually trying to
use that feature, and applications/servers that are especially
sensitive to fingerprinting (e.g. the Tor Browser) may cleanly avoid
the issue by disabling 0-RTT handshake support, as a worst-case
option.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)