Subject: [TLS] Server time

From: Dave Garrett <[email-masked]>
Date: Sat, 4 Apr 2015 13:52:12 -0400

And now, a simple issue with a simple solution:

https://github.com/tlswg/tls13-spec/issues/64

Consensus was to drop time from the random fields. Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. (note that ServerHello is already changed by dropping compression_method)

The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost.

Dave

---

From: Erik Nygren <[email-masked]>
Date: Sat, 4 Apr 2015 15:53:31 -0400

If we do, can we please make the extension y2038 safe?  With 17 years to go
when this launches, that will be the same age as tls 1.0 and older than
sslv3.

It does seem like a useful server hello extension, however, as long as
clients wait for a complete and authenticated handshake before using it.

      Erik

Sent from my mobile device
And now, a simple issue with a simple solution:

Consensus was to drop time from the random fields. Prohibiting non-random
in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS
1.3+ seems like a really simple solution. (note that ServerHello is already
changed by dropping compression_method)

The ability of a client to sanity check or sync its time seems like
something worth having, especially for only a 4 byte cost.

Dave

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 4 Apr 2015 17:09:07 -0400

> Consensus was to drop time from the random fields. Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. (note t…
+1. Random should be random. Placing time in the random field meant
the field was not used for its intended purpose. It violated the
engineering design. (Whether it resulted in a vulnerability is a
different debate).

> The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost.
+1. Some Android phones have a peculiarity where they will fail their
very first path validation (like after a factory reset). The phones
don't have a SIM and use Wifi. We think its because of the clock (we
have never been able to duplicate it, but I've seen the field
reports).

Other older phones have the same issue, but its persistent. That is,
the phone won't set the time if there's no network. You have to SIM
the phone or manually set the time.

I think the same problem will arise in the future with the Internet of
Things. Refrigerators and thermostats will experience similar issues.
History has a tendency to repeat itself.

The time field begs the question: what is the presentation of time? Is
it a UTC or GMT time? Is it a local time? Is there time zone data
associated with it?

---

From: Dave Garrett <[email-masked]>
Date: Sat, 4 Apr 2015 17:09:27 -0400

> when this launches, that will be the same age as tls 1.0 and older than

Yeah, I suggested uint32, which will last the century. Not worth the extra 4 bytes to go 64-bit, IMO. Nobody should be still using this at the beginning of the 22nd century. (if someone does, and is looking back in time in the archives: upgrade your crap)

The previous not-random-but-in-random time was uint32 as well, so that was fine so long as clients actually handled it properly. A warning could be added about signage saying not to ever treat it as signed and that after reading as uint32, it should probably be handled as int64 or whatever type the implementation uses for time values.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 4 Apr 2015 17:57:05 -0400

> clients wait for a complete and authenticated handshake before using it.

Just sticking in an extra ServerHello field for the time is the quick and simple replacement for the old standardized hack. If we want more, it wouldn't be difficult to write a simple time/ping protocol to build into the spec. Do a ping with a time request after authentication and it would be protected, measure latency, and easily provide precise remote time adjusted for response time. Might be overkill, though it'd be simple enough to add.

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 4 Apr 2015 18:10:09 -0400

On Sat, Apr 4, 2015 at 5:57 PM, Dave Garrett <[email-masked]> wrote:
> ...
>
> Do a ping with a time request after authentication and it would be protected, measure latency, and easily provide precise remote time adjusted for response time. Might be overkill, though it'd be simple enough to add.
>
I think the problem here is channel setup will fail *if* the client's
clock is wrong. The client will fail to validate the end-entity
certificate due to problems with the notBefore and notAtfer (even
though its correct). You won't have a channel to perform the ping.

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.

Jeff

---

From: Hauke Mehrtens <[email-masked]>
Date: Sun, 05 Apr 2015 18:32:31 +0200

> though its correct). You won't have a channel to perform the ping.

If the client trusts the servers clock the notBefore and notAtfer check
is useless, because a bad server could change the time of the check to a
value where the certificate check is valid. If you take the time from
the same entity where you get your certificate to check from the time
check is useless.

There is a big problem with embedded devices, which do not have a real
time clock.

One solution would be that you burn a valid certificate or CA
certificate into a firmware and your device trusts this certificate
regardless of the validity period. And this server could be used to get
the time from. But wouldn't it be better to deign this as an extra
protocol on top of TLS/DTLS?

The German electronic identity card is unable to do any online checks
and does not have a real time clock. It stores the issue date of the
most recent certificate it saw and checks every other certificate if it
was at least valid at this date. (The certificates used there are
normally only valid for some days and there is no revocation mechanism)

> successfully, then the client can decide if it wants to accept the

Adding such a field could also result in some stupid developers using
this field to check if the certificate is valid for every handshake.

---

From: Brian Smith <[email-masked]>
Date: Sun, 5 Apr 2015 08:11:49 -1000

Dave Garrett <[email-masked]> wrote:
> Consensus was to drop time from the random fields.

Right.

> Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution.

What problem does it solve?

> (note that ServerHello is already changed by dropping compression_method)

That seems unnecessary to me. compression_method could/should just be
fixed to be "null", avoiding unnecessary compatibility risk.

> The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost.

The client can sanity check or sync its time using other mechanisms
already, even with earlier versions of TLS. I don't see how adding a
time field to ServerHello would help solve that problem.

There may be occasions when the server and client need to sync time,
e.g. if it helps the 0-RTT handshake in some way. But, that should be
done as part of the specification for whatever mechanisms require it.
See the long-ago discussion about this [0].

Keep in mind that we removed the time from the Hello random fields
because they leaked information that made it easier to track clients.
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.

Cheers,
Brian

[0] https://www.ietf.org/mail-archive/web/tls/current/msg10861.html

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 5 Apr 2015 14:31:30 -0400

> because they leaked information that made it easier to track clients.

Tracking and anonymity has a different solution. I don't understand
how folks can claim they are solving this when the first TCP SYN
usually begins the tracking process. What happens after the TCP stream
begins is irrelevant.

> NOT say what time it thinks it is.

In this case, allow a value of 0. In RFC 1952 (GZIP file format
specification), a MTIME of 0 means no time is available.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Apr 2015 12:03:51 -0700

On Sun, Apr 5, 2015 at 11:11 AM, Brian Smith <[email-masked]> wrote:

> > Prohibiting non-random in ServerHello.random and adding a 4 byte uint32
> ServerHello.time for TLS 1.3+ seems like a really simple solution.
>

I think I agree with this, actually.

Filed https://github.com/tlswg/tls13-spec/issues/161 so we don't lose
this comment.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sun, 5 Apr 2015 16:06:17 -0400

> 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