Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

Subodh Iyengar <> Thu, 23 July 2015 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0047C1A89FA for <>; Thu, 23 Jul 2015 10:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 t7nEgMd80pvZ for <>; Thu, 23 Jul 2015 10:28:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 451701A9068 for <>; Thu, 23 Jul 2015 10:27:55 -0700 (PDT)
Received: from pps.filterd (m0004347 []) by (8.14.5/8.14.5) with SMTP id t6NHOx3Q029245; Thu, 23 Jul 2015 10:27:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=cgd9kJCvABp0euopTWNNogSPnGsTEVh7vrOZSH2yGIw=; b=g56K9RSqxo9EvA4QdWPIsetXhO/K8RiVKgUhrjdJTpUuS8nL2KYLelmVqSOcJBEtS3TE grkDEcVDY1SxgX2l1aLLVwVQVx7FlKRTMSPex7hj4QgxLrELf8t8NFN0mCUr475JZJrW tzsIh1fIgSCk0HbRfDq9F/NzcTiEzqy/bls=
Received: from ([]) by with ESMTP id 1vu4jxg0eq-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2015 10:27:55 -0700
Received: from ([]) by ([fe80::7ded:c10e:ef04:80d8%12]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 10:26:15 -0700
From: Subodh Iyengar <>
To: Hubert Kario <>, "" <>
Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date
Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3pXhaA///uI1c=
Date: Thu, 23 Jul 2015 17:26:14 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
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-23_09:2015-07-22,2015-07-23,1970-01-01 signatures=0
Archived-At: <>
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: Thu, 23 Jul 2015 17:28:31 -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. 

Subodh Iyengar

From: TLS [] on behalf of Hubert Kario []
Sent: Thursday, July 23, 2015 4:16 AM
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

On Wednesday 22 July 2015 19:55:58 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.

the hint on tickets is already relative, so +1 on relative in server
configuration too
Hubert Kario
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic