IETF Logo Mail Archive

Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 23 July 2015 08:24 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B401A8ABD for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 01:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJEyyjd0t4qE for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 01:24:22 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6DA1A8AAA for <tls@ietf.org>; Thu, 23 Jul 2015 01:24:22 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 23 Jul 2015 08:24:20 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Thu, 23 Jul 2015 08:24:20 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>, Bill Frantz <frantz@pwpconsult.com>
Thread-Topic: [TLS] Relative vs absolute ServerConfiguration.expiration_date
Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dZ3n6FoAgAAPa4CAAAEWAIAABIqAgABJxgCAADjqAIAANzGQ
Date: Thu, 23 Jul 2015 08:24:20 +0000
Message-ID: <BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <45822829-5DA1-4AA8-9317-BE4D4AEC41E6@fb.com> <r422Ps-1075i-2B99FA179EAA462989B17C5443053D7F@Williams-MacBook-Pro.local> <CABcZeBPWG92TTwKGBO3ecYKez29vUJJs0fdhDXxT6M7DsV-HjA@mail.gmail.com>
In-Reply-To: <CABcZeBPWG92TTwKGBO3ecYKez29vUJJs0fdhDXxT6M7DsV-HjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [90.181.160.186]
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: <BLUPR03MB13960FE64089FD2B5D49195F8C820@BLUPR03MB1396.namprd03.prod.outlook.com>
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; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396A23A468A6FE6CFF0B3DD8C820BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
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: <http://mailarchive.ietf.org/arch/msg/tls/UUW9Gk0r_LCSptaa5tudDGSEpJI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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.

Cheers,

Andrei

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



On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz <frantz@pwpconsult.com<mailto:frantz@pwpconsult.com>> 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, bmatheny@fb.com<mailto:bmatheny@fb.com> (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" <ekr@rtfm.com<mailto:ekr@rtfm.com>> 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
TLS@ietf.org<mailto:TLS@ietf.org>
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

v2.23.0 | Report a Bug | By Email