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

[Nick Mathewson <[e-mail]>]

On Fri, Dec 6, 2013 at 3: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.

This is a neat idea, and much more effective at randomization than at
hiding the client's view of the current time.

I believe that the QUIC crypto spec mentioned a similar idea (but
dismissed it in favor of another solution): "The first of these issues
could be addressed by having the clients take a clock-sync signal from
the server and define a “server local time” offset for that server."

One caveat here is that a server could tell different clients that it
had different skew values, thereby creating yet another way to set
stealth cookies.  You'd need to be sure not to share your view of
server-local time across anonymous sessions, while roaming in a
privacy-conscious way, and so on.

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

I'd agree that this is an improvement over sending gmt_unix_time to
everybody indiscriminately, surely, though you would (as Wan-Teh Chang
notes) need to change the inputs to the KDF a bit.  It doesn't seem
like an insurmountable obstacle by any means, though.

best wishes,
-- 
Nick Mathewson