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

[Wan-Teh Chang <[e-mail]>]

On Fri, Dec 6, 2013 at 12:14 PM, Brian Smith <[e-mail]> wrote:
> 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.

I think this solution may also work. It is in fact that first solution
I considered. After I came up with the simpler random clock skew idea,
I stopped pursuing this further.

> 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.

This is a good idea. However, this idea needs a little more work
because the timestamp must be part of the nonce input to the key
derivation function (the TLS PRF) in this anti-replay mechanism. So
the key derivation process for 0-RTT handshakes needs to also take the
timestamp in the 0-RTT handshake extension as input.

Wan-Teh Chang