Subject: [TLS] Issue #348: 32bit timestamp in ServerConfiguration

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 10:28:41 -0800

>From the issue:

<<<
As far as I can see, the only timestamp used is expiration_date in the
ServerConfiguration (apart from X.509 validity checks which require
synchronised clocks). This is defined as seconds since UNIX epoch, and
will overflow sooner than later. Maybe either use a relative amount of
seconds here, or expand to a 64bit value!?

I suggest to use 32bit network byte order (same as
ticket_lifetime_hint), which value are the seconds how long this
configuration is valid, and thus may be cached for at most this amount
of seconds.

I don't want to see this change to a relative time.  That will mess
with our ability to create ServerConfiguration objects that live
outside of the handshake.

I have no real objection to expanding this to 64bit though.  (I'm
personally OK with stating that this is modulo 2^32, but recognize how
that might result in problems.)

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 Nov 2015 20:56:50 +0200

> that might result in problems.)

I got the idea of using 32-bit sequence number arithmetic there too
(window is -2G to 2G seconds around current time). I don't suppose
any key will need to have TTL of over ~68 years...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 11:02:14 -0800

> any key will need to have TTL of over ~68 years...

I did too, but decoded that 2^64 is just easier.