I guess what I'm trying to get at is the following: Are there a lot of people whose clocks are accurate enough that they will be able to connect to the server and check the certificate/OCSP but not accurate enough to process ServerConfiguration if it is in absolute time.
On Wed, Jul 22, 2015 at 10:54 PM, Blake Matheny <bmath...@fb.com> wrote: > 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. > > > 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
