Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

>    On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny <[e-mail]> 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
>