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

[Stephen Farrell <[e-mail]>]

This [1] is probably also relevant.

S

[1] http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/

On 12/06/2013 08:14 PM, Brian Smith 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.
> 
> 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
>