Re: [TLS] Server time

[Dave Garrett <[e-mail]>]

On Saturday, April 04, 2015 06:10:09 pm Jeffrey Walton wrote:
> I like the idea of a field like ServerHello.time so the server can
> communicate its belief in time. A client can defer a simple failure
> based on time until key exchange completes. If key exchange completes
> successfully, then the client can decide if it wants to accept the
> server's view of time.
> 
> The functionality leads to other attack surfaces, like a rogue server
> rolling back its time and using compromised key. But I think that can
> be solved with a good degree of certainty using Guttmann's security
> diversification techniques.

On Sunday, April 05, 2015 12:32:31 pm Hauke Mehrtens wrote:
> Adding such a field could also result in some stupid developers using
> this field to check if the certificate is valid for every handshake.

On Sunday, April 05, 2015 02:11:49 pm Brian Smith wrote:
> 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.

The problems have solutions, but ones that would need to be implemented carefully. In particular, the safest way to handle servers needing time privacy would be to make ServerHello.time the last field, and simply not include it when not desired. (rather than zeroing it out)

Unauthenticated time is safe for sanity checking the client time, but relying on it to verify anything as opposed to just rejecting would be bad. Unauthenticated time sync is a far more narrow case that probably isn't worth having for the general case.

The above is sufficient to convince me that unauthenticated time in the ServerHello is not likely to be worth the risk in the general case. It's not idiot-proof enough.

The time could be integrated elsewhere into the handshake and authenticated, but now it's no longer simple. A basic ping/time protocol would be really simple, though, it'd have to be after the handshake.

As to the actual issue #64, fully prohibiting time in the random field entirely seems appropriate, however. That part seems simple enough. As noted by Brian, not doing so allows the time to accidentally be leaked in P2P usage.


Dave