Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

Eric Rescorla <> Wed, 22 July 2015 20:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3C2B1B2E3E for <>; Wed, 22 Jul 2015 13:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H7SsWmFmkQNn for <>; Wed, 22 Jul 2015 13:59:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E75C1A1B7B for <>; Wed, 22 Jul 2015 13:59:05 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so190473492wib.0 for <>; Wed, 22 Jul 2015 13:59:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4WuVN2F6+WJB2Hr5nQR/ezCe2mtLpeM9jcpp8SXI2lM=; b=nMpvVZk+G15BN+gtly8Kdu8jqSgvoCF59tPwpXLJQKzaplcf5fPVYf2XtX/7E2Jpzg PpsVlPP/NvfjRdbFy7NGqUSNElNZRRbrBxVO2NbaCzuy9OGLFj6wLgp08Lv8DHxBiR9k 7v7iFnuU7h99qRfKAZnwN8TRRuJphnha9+oydl3x3dDHgWy+g8t+5P4F1o2MxYtZX8ya uZrQMo+tmix0LEc2DB/JJvpeTZ1/9ESRPsfgY59nVWe5XIAuIrZHEOIduOUa2gd3hWnP XgsY2XoFG111+CPUk/Sb1wLvp/Oz8d8/4ynSvuAOteDf9skIQOXN7vl3gaZGMSsNgklr 1hjQ==
X-Gm-Message-State: ALoCoQkfMnuzBxZtVA1ehhJmojlDh0BBgwypBBo27CjO7DTWw7GqDMw2dwGDmnk44Pc3KPkwdq7k
X-Received: by with SMTP id pa9mr8699772wjb.148.1437598743941; Wed, 22 Jul 2015 13:59:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Jul 2015 13:58:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Eric Rescorla <>
Date: Wed, 22 Jul 2015 22:58:24 +0200
Message-ID: <>
To: Blake Matheny <>
Content-Type: multipart/alternative; boundary=089e011771a976675f051b7d0aab
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:59:07 -0000

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.

On Wed, Jul 22, 2015 at 10:54 PM, Blake Matheny <> wrote:

>    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?
>  -Blake