Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

Andrei Popov <> Thu, 23 July 2015 08:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49B401A8ABD for <>; Thu, 23 Jul 2015 01:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SJEyyjd0t4qE for <>; Thu, 23 Jul 2015 01:24:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F6DA1A8AAA for <>; Thu, 23 Jul 2015 01:24:22 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 23 Jul 2015 08:24:20 +0000
Received: from ([]) by ([]) with mapi id 15.01.0225.018; Thu, 23 Jul 2015 08:24:20 +0000
From: Andrei Popov <>
To: Eric Rescorla <>, Bill Frantz <>
Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date
Date: Thu, 23 Jul 2015 08:24:20 +0000
Message-ID: <>
References: <> <r422Ps-1075i-2B99FA179EAA462989B17C5443053D7F@Williams-MacBook-Pro.local> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:rgUvtX4/C8jMxrd1QYbqxyUXBmVQ9fPVrIfrl4KH/gbbNFSqbptrh7goyEZRbXR7ygXqZJV4IeUiPPD53jYi9css0V2F3asbUqXznXWnD0lJUr7x4VZY9nDzAzuFTNA56CdJ9Rz3SDTJg8X8mX8oyA==; 24:nilJgKdzX3M8Zge5sLu0/cpi1zJaBrgwlIjE3YdeaWOCJqx0EAzWdfLcNhrnENElBn921sgV+BK+tSWdW5v4ZtvMbU2UVmKMmwwvE6OI6/4=; 20:vd8k1UCDTcgGitzccWd8v0Uk5RHpoRukPAoF43apiFW/9RFY6SWVjXPq+vW1RBItxhnlX9JfiwUSX2stSjKP7Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396;
x-forefront-prvs: 06469BCC91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(377454003)(24454002)(54356999)(77096005)(66066001)(62966003)(33656002)(16601075003)(77156002)(19580405001)(15975445007)(99286002)(102836002)(189998001)(19625215002)(19617315012)(5003600100002)(106116001)(76176999)(2950100001)(87936001)(76576001)(16236675004)(2656002)(5001920100001)(5001960100002)(46102003)(19300405004)(122556002)(19580395003)(5001770100001)(10090500001)(92566002)(74316001)(5002640100001)(40100003)(86362001)(19609705001)(2900100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820BLUPR03MB1396namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 08:24:20.3216 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
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: Thu, 23 Jul 2015 08:24:24 -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.



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

On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz <<>> 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)


Cheers - Bill

On 7/22/15 at 2:14 PM,<> (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.


On 7/22/15, 10:58 PM, "Eric Rescorla" <<>> 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<>
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506<tel:%28408%29356-8506>      | contact sport.               | 16345 Englewood Ave<> |  - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032