On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny <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. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
