Re: [openpgp] Dealing with clock skew
"Derek Atkins" <derek@ihtfp.com> Fri, 15 November 2019 12:03 UTC
Return-Path: <derek@ihtfp.com>
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 0F65A120824 for <openpgp@ietfa.amsl.com>; Fri, 15 Nov 2019 04:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com
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 B-HBrS6ZqekR for <openpgp@ietfa.amsl.com>; Fri, 15 Nov 2019 04:03:04 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F65120823 for <openpgp@ietf.org>; Fri, 15 Nov 2019 04:03:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 80C62E2040; Fri, 15 Nov 2019 06:38:13 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10511-04; Fri, 15 Nov 2019 06:38:06 -0500 (EST)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 1C05BE2044; Fri, 15 Nov 2019 06:38:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1573817886; bh=4hUH9krsRgR0/Vilyi7nYViMOU07lOHB149aNhUnS3Y=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=G3avkb8MjV3ZyeSFFLAJsdEKRxQVPgG5D+UbqjiqGP7iq0hF8CRTtqlkBfk+TfT/6 qO/jbzmHsmPsByWRjCoXcZzUCIxSQimGDIv7t+v/8fKpCgcvcH8datexXbSV9uzIAK ty1PU4LMwbMbO96W5q3L+mHjK6TLZmv/xu0RduBs=
Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 15 Nov 2019 06:38:06 -0500
Message-ID: <d424523b331984a39fdf1c87b7052a49.squirrel@mail2.ihtfp.org>
In-Reply-To: <87zhgxo0bm.wl-neal@walfield.org>
References: <87zhgxo0bm.wl-neal@walfield.org>
Date: Fri, 15 Nov 2019 06:38:06 -0500
From: Derek Atkins <derek@ihtfp.com>
To: "Neal H. Walfield" <neal@walfield.org>
Cc: openpgp@ietf.org
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/rFcO6LyQusY6BPJT4G8EB6bskk4>
Subject: Re: [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 12:03:06 -0000
Hi Neal, There is plenty of prior art on dealing with time skew. Kerberos, for example, has been dealing with it since the 1980s! In short, you have a sliding window of acceptance. Kerberos sets this as +/- 5 minutes. So if the timestamp is within that 10-minute range it is considered current (valid). If you are seeing 20-minute clock skew on a VM, then you should really set up ntp. As for your second issue, my questions to you are: 1) are the messages are guaranteed to be in order (or could they be reordered). 2) can the validator maintain per-sender state? If YES to both questions, then the easiest thing to do is maintain the last timestamp sent and reject if the next message has a timestamp prior to the last one seen. Note that this state must be per-sender, so if you have Alice talking to Bob and Charlie, Alice needs to maintain separate last-seen numbers for both Bob and Charlie, because their clocks can be skewed differently. Hope this helps, -derek On Fri, November 15, 2019 6:17 am, Neal H. Walfield wrote: > 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 mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
- [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