Subject: [TLS] Relative vs absolute ServerConfiguration.expiration_date

From: Blake Matheny <[email-masked]>
Date: Wed, 22 Jul 2015 19:55:58 +0000

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?

-Blake

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Jul 2015 21:59:20 +0200

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

---

From: Blake Matheny <[email-masked]>
Date: Wed, 22 Jul 2015 20:54:31 +0000

On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny <[email-masked]<mailto:[email-masked]>> 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.

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Jul 2015 22:58:24 +0200

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 <[email-masked]> wrote:

>  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
>

---

From: Blake Matheny <[email-masked]>
Date: Wed, 22 Jul 2015 21:14:39 +0000

Ahh. I can't tell, the data I have is only clients with very very broken clocks who failed validation as a result. My assumption would be that there is a much larger number of clients that fit what you described (cert/OCSP check passes, but ServerConfiguration would not be). Since I don’t have the data, I can’t say that for sure, but anecdotal evidence would indicate that this is the case.

-Blake

On 7/22/15, 10:58 PM, "Eric Rescorla" <[email-masked]> wrote:

>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.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 22 Jul 2015 18:38:42 -0700

One place we may run into a lot of those clients are on machines 
like the Raspberry Pi and Beaglebone machines. These boards do 
not include clock chips, so the machines must get the current 
time via NTP every time they power on. If there is a problem 
with NTP, or if the shell script to set the clock is not run, 
then the date will probably be 20 or 30 years back in the last millenium.

Cheers - Bill

On 7/22/15 at 2:14 PM, [email-masked] (Blake Matheny) wrote:

>Ahh. I can't tell, the data I have is only clients with very 
>very broken clocks who failed validation as a result. My 
>assumption would be that there is a much larger number of 
>clients that fit what you described (cert/OCSP check passes, 
>but ServerConfiguration would not be). Since I don’t have the 
>data, I can’t say that for sure, but anecdotal evidence would 
>indicate that this is the case.
>
>-Blake
>
>
>
>
>>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.
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls
>
-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506      | contact sport.               | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Jul 2015 07:02:24 +0200

On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz <[email-masked]> wrote:

> One place we may run into a lot of those clients are on machines like the
> Raspberry Pi and Beaglebone machines. These boards do not include clock
> chips, so the machines must get the current time via NTP every time they
> power on. If there is a problem with NTP, or if the shell script to set the
> clock is not run, then the date will probably be 20 or 30 years back in the
> last millenium.
>

That's definitely a problem, but not a specific problem for
ServerConfiguration since those implementations will also have problems
with certificates (and ironically, will accept ServerConfiguration just
fine)

-Ekr

Cheers - Bill

>  Ahh. I can't tell, the data I have is only clients with very very broken
>> clocks who failed validation as a result. My assumption would be that there
>> is a much larger number of clients that fit what you described (cert/OCSP
>> check passes, but ServerConfiguration would not be). Since I don’t have the
>> data, I can’t say that for sure, but anecdotal evidence would indicate that
>> this is the case.
>>
>> -Blake
>>
>>
>>
>>
>> server and check the certificate/OCSP but not accurate enough to process
>> ServerConfiguration if it is in absolute time.
> (408)356-8506      | contact sport.               | 16345 Englewood Ave
> www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032
>
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Jul 2015 08:24:20 +0000

Our telemetry shows that there are tons of machines (including recently manufactured tablets) without persistent clocks (i.e. no battery powering the system clock). Such machines indeed boot with date/time in the past millennium; they cannot hard-fail on OCSP errors (which greatly reduces the value of OCSP).

If we can avoid creating the same issue for ServerConfiguration, I think we should.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, July 23, 2015 7:02 AM
To: Bill Frantz
Cc: [email-masked]
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz <[email-masked]<mailto:[email-masked]>> wrote:
One place we may run into a lot of those clients are on machines like the Raspberry Pi and Beaglebone machines. These boards do not include clock chips, so the machines must get the current time via NTP every time they power on. If there is a problem with NTP, or if the shell script to set the clock is not run, then the date will probably be 20 or 30 years back in the last millenium.

That's definitely a problem, but not a specific problem for ServerConfiguration since those implementations will also have problems
with certificates (and ironically, will accept ServerConfiguration just fine)

-Ekr

Cheers - Bill

On 7/22/15 at 2:14 PM, [email-masked]<mailto:[email-masked]> (Blake Matheny) wrote:
Ahh. I can't tell, the data I have is only clients with very very broken clocks who failed validation as a result. My assumption would be that there is a much larger number of clients that fit what you described (cert/OCSP check passes, but ServerConfiguration would not be). Since I don’t have the data, I can’t say that for sure, but anecdotal evidence would indicate that this is the case.

-Blake

On 7/22/15, 10:58 PM, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:
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.
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls
-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506<tel:%28408%29356-8506>      | contact sport.               | 16345 Englewood Ave
www.pwpconsult.com<http://www.pwpconsult.com> |  - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Jul 2015 13:16:59 +0200

> 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
 
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

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 23 Jul 2015 17:26:14 +0000

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 [[email-masked]] on behalf of Hubert Kario [[email-masked]]
Sent: Thursday, July 23, 2015 4:16 AM
To: [email-masked]
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date