On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny <bmath...@fb.com<mailto:bmath...@fb.com>> 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. Thoughts or feedback? Can you provide a sense of the range of clock skew you are seeing? I'm trying to figure out how many of these clients are going to start choking with OCSP must-staple, short-lived certs, etc. Well, our public cert is set to expire in ~1 year. The errors I’m seeing are “certificate has expired” and “certificate not yet valid”. I don’t have client timestamp vs server timestamp, but the clock in these cases is off by a year-ish? -Blake
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
