[TLS] Relative vs absolute ServerConfiguration.expiration_date

Blake Matheny <bmatheny@fb.com> Wed, 22 July 2015 19:56 UTC

Return-Path: <prvs=46459d10f6=bmatheny@fb.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 7F7CF1ACEAF for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 12:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.468
X-Spam-Level:
X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_0CLCqjjfhI for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 12:56:01 -0700 (PDT)
Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D711ACEA4 for <tls@ietf.org>; Wed, 22 Jul 2015 12:56:00 -0700 (PDT)
Received: from pps.filterd (m0004077 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t6MJrYab030744 for <tls@ietf.org>; Wed, 22 Jul 2015 12:56:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=jyVowcIbcksFqxbr18hLeZrXSrbbauDIS/hKaaYKNuQ=; b=WGZIfsriGXmWyHmpYb4OmMNlqRTGJyxWfYqBkZ2HX3zMnnKmd22FI/4XS1tZ+pkuyGil Y9k+GuR2GDWBsu3ekyB+5xHWr1hmeDu/r3mQ1dkJ0V5sYOAOIAL3us9ibZMuKSfIGgr5 JOrY0gqIGQpjuxt2Cjuf3rsY8kzlfpEe6/k=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1vtg0t0gcs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <tls@ietf.org>; Wed, 22 Jul 2015 12:56:00 -0700
Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.114]) by PRN-CHUB12.TheFacebook.com ([fe80::ddee:413f:3120:8216%12]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:55:58 -0700
From: Blake Matheny <bmatheny@fb.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Relative vs absolute ServerConfiguration.expiration_date
Thread-Index: AQHQxLhtAHKzuQna7EW41OtNBaA7dQ==
Date: Wed, 22 Jul 2015 19:55:58 +0000
Message-ID: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [192.168.54.13]
Content-Type: text/plain; charset="utf-8"
Content-ID: <53085D9F55D9B24BB9D064544E52422A@fb.com>
Content-Transfer-Encoding: base64
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: <http://mailarchive.ietf.org/arch/msg/tls/qtyFGMNrBk0_OabSuBqTZ-t7XDo>
Subject: [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: Wed, 22 Jul 2015 19:56:02 -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