[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [217.69.77.164]) (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 ([84.171.221.1] 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 ([192.168.20.9] 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 (Gojō) 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-Connect-IP: 192.168.20.9
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
Hi, 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? Thanks! :) Neal
- [openpgp] Dealing with clock skew Neal H. Walfield
- Re: [openpgp] Dealing with clock skew Derek Atkins
- Re: [openpgp] Dealing with clock skew Bill Frantz
- Re: [openpgp] Dealing with clock skew Claudio Luck
- Re: [openpgp] Dealing with clock skew Jon Callas
- Re: [openpgp] Dealing with clock skew Benjamin Kaduk
- Re: [openpgp] Dealing with clock skew Phillip Hallam-Baker