Our data suggests that during successful handshakes the clock skew of mobile devices is within a few hours, and is within years for unsuccessful cases. Having relative time thus is definitely better from the client's perspective.
With this however, there is a tradeoff on the server. The expiry time for the config is signed into the server config itself. So if the server wants to expire its server config in a predictable way it probably needs to resign it periodically. This adds some operational issues on the server, for example performance, and becomes more operationally challenging in situations where there is cryptographic offloading to either a different process or a different box. If we can come up with a reasonable solution to the resigning problem, then relative time seems superior. Cheers, Subodh Iyengar ________________________________________ From: TLS [tls-boun...@ietf.org] on behalf of Hubert Kario [hka...@redhat.com] Sent: Thursday, July 23, 2015 4:16 AM To: tls@ietf.org Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote: > One of the topics of discussion at the WG discussion was whether > ServerConfiguration.expiration_date should be an absolute or relative > value. Subodh (CC) dug into our production data and found that nearly half > of the TLS errors we see in production (end user to edge/origin) are due to > date mismatch. This often occurs when people intentionally reset the clock > on their phone, or for other various reasons. > Due to the high rate of date mismatch errors we see, my preference would be > that ServerConfiguration.expiration_date be a relative value instead of an > absolute one. This provides the client an opportunity to correctly use a > monotonic (or other similar) clock to minimizing exposure, without losing > the value of the ServerConfiguration. Using an absolute value means that > ServerConfiguration, for clients with invalid clocks, would essentially > never be cacheable. These clients wouldn’t benefit from > ServerConfiguration. the hint on tickets is already relative, so +1 on relative in server configuration too -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
