Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

Eric Rescorla <ekr@rtfm.com> Wed, 22 July 2015 20:59 UTC

Return-Path: <ekr@rtfm.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 F3C2B1B2E3E for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 13:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7SsWmFmkQNn for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 13:59:05 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E75C1A1B7B for <tls@ietf.org>; Wed, 22 Jul 2015 13:59:05 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so190473492wib.0 for <tls@ietf.org>; Wed, 22 Jul 2015 13:59:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.194.133.73 with SMTP id pa9mr8699772wjb.148.1437598743941; Wed, 22 Jul 2015 13:59:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Wed, 22 Jul 2015 13:58:24 -0700 (PDT)
In-Reply-To: <3D04F5AE-61E1-45A9-A794-C3F0E6F3DEAD@fb.com>
References: <8965F344-4921-4F99-8A5A-BA7BCAAB0D7C@fb.com> <CABcZeBPTnXzDwoGTS5=m7mzaxiZtqKzMG33ghTzFcJSbFQyAsQ@mail.gmail.com> <3D04F5AE-61E1-45A9-A794-C3F0E6F3DEAD@fb.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 22 Jul 2015 22:58:24 +0200
Message-ID: <CABcZeBN_3fXKSrNCyhL5FY+VOu_wG8EH9oKAe2Ss3KOn1dU8cA@mail.gmail.com>
To: Blake Matheny <bmatheny@fb.com>
Content-Type: multipart/alternative; boundary=089e011771a976675f051b7d0aab
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/w9-tQQKx4XAJSxPug7STHT08k_Q>
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: 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 <bmatheny@fb.com> wrote:

>    On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny <bmatheny@fb.com> 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
>