Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

[Subodh Iyengar <[e-mail]>]

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 [[e-mail]] on behalf of Hubert Kario [[e-mail]]
Sent: Thursday, July 23, 2015 4:16 AM
To: [e-mail]
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