Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

Blake Matheny <> Wed, 22 July 2015 20:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AD4FC1B2E4F for <>; Wed, 22 Jul 2015 13:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gKpoKWisGsyU for <>; Wed, 22 Jul 2015 13:56:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29C501B2E3E for <>; Wed, 22 Jul 2015 13:56:03 -0700 (PDT)
Received: from pps.filterd (m0004003 []) by (8.14.5/8.14.5) with SMTP id t6MKtwh4012545; Wed, 22 Jul 2015 13:56:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Bl17ncmqOabxf78llRnJH11t6TLStD+baHhSHzjwby4=; b=VZ214d/4/k6Z0sk5JYFQVkmUxcjRqOL3h0cUUFCgTdjo6L8xWYTMksApLmdqh3Je5FFu FdEmP6I6oq+aUcVqoElUp4L04wmisxwlEyGFCq5wfTmo/VyOyP3Y45YPApr62JbdV6Y0 B8Kd1j/5Rb7haYSSPLwXaCCP4AeG2KOgIQw=
Received: from ([]) by with ESMTP id 1vtg1j8qbs-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 13:56:03 -0700
Received: from ([]) by ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:54:32 -0700
From: Blake Matheny <>
To: Eric Rescorla <>
Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date
Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3oXbMAgAAw8oA=
Date: Wed, 22 Jul 2015 20:54:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_3D04F5AE61E145A9A794C3F0E6F3DEADfbcom_"
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-22_07:2015-07-22,2015-07-22,1970-01-01 signatures=0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 20:56:05 -0000

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