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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp