[openpgp] Dealing with clock skew

"Neal H. Walfield" <neal@walfield.org> Fri, 15 November 2019 11:17 UTC

Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4191712080E for <openpgp@ietfa.amsl.com>; Fri, 15 Nov 2019 03:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FD4tWqxMgC-T for <openpgp@ietfa.amsl.com>; Fri, 15 Nov 2019 03:17:52 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de []) (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 357351207FC for <openpgp@ietf.org>; Fri, 15 Nov 2019 03:17:51 -0800 (PST)
Received: from p54abdd01.dip0.t-ipconnect.de ([] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1iVZbp-000104-So for openpgp@ietf.org; Fri, 15 Nov 2019 11:17:49 +0000
Received: from grit.huenfield.org ([] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1iVZbp-00058R-7l for openpgp@ietf.org; Fri, 15 Nov 2019 12:17:49 +0100
Date: Fri, 15 Nov 2019 12:17:49 +0100
Message-ID: <87zhgxo0bm.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: openpgp@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/IIkgUwfgyIEnRAOwpMEhxiDw550>
Subject: [openpgp] Dealing with clock skew
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2019 11:17:54 -0000


Our OpenPGP library is being used in an application that does a
real-time exchange.  Specifically, two MUAs sometimes communicate via
an imap folder.  During testing, the application developers observed
that the message exchange would sometimes fail, because a signature
was considered invalid.

Eventually, we figured out that the problem was due to clock skew: the
sender would sign a message at, say, 9:00 and the receiver would
correctly reject it because its clock said that the current time was
8:59, and 9:00, the time stored in the message's Signature Creation
Time subpacket, is clearly in the future.

It turns out that a second of clock skew is actually pretty good.  The
testing was done on a VM and the application developer reported that
up to 20 minutes of clock skew are not unusual.

Adding a tolerance seems like a reasonable way to deal with this
problem.  But, there are situations where a tolerance would cause
other problems.  Consider, for instance, an application that generates
messages that contain its current state, and we want to know its state
at some point in time.  Specifically, consider messages, Ma and Mb,
and a time T.  If Ta < T < Tb (< current time), then we should use Ma.
But, if T is significantly close to Tb, we may not reject Mb and use
it instead!

An obvious example of this type of message is self signatures.  It is
tempting to just not use tolerances with self-signatures, but if an
application generates a key, and immediately sends it to another
computer, the second computer may reject the key as being invalid,
because it doesn't consider it to have any valid self-signatures!  So,
some tolerance is also needed for self signatures.  Also, the example
also applies to normal ("user data") messages, so specially handling
self-signatures is not the right approach, anyway.

Perhaps the best thing to do is to only use a tolerance when asking if
a signature is valid "now".

How do other implementations deal with this?  Thoughts?


:) Neal