-
Notifications
You must be signed in to change notification settings - Fork 282
Monitor should gracefully handle old STHs. #124
Comments
After running the monitor (C++) for a while now, we've noticed strange behaviour. We've received some STH $A. After a while we've received a newer STH $B and then we've received the old STH $A, again. Details: On 04:15 Am the following STH was provided until 05:00 AM. Then the older STH was delivered by the log on 05:01 AM, again. In its current implementation the monitor (C++) would treat this as misbehaviour - because we thought this actually is misbehaviour. Is this correct? If so, what happened on your side? |
I don't know whether the team running the Google log servers consider this behaviour to be a bug, but the behaviour seems compliant with RFC 6962. The only relevant requirements on the response of get-sth are: In the behaviour you observed, the STHs are within the log's MMD[0]. Notably, RFC 6962 does not require that responses to get-sth be in-order (with respect to tree_size). I suspect such a requirement would be too constraining for a distributed system (which production-quality log servers inevitably end up being). Given this, monitors should gracefully handle old STHs. Note that "gracefully handle old STHs" doesn't mean ignoring them and asking for a new STH. To see why, suppose upon querying get-sth three times, you receive the following three STHs (all within the MMD): In this case, a monitor must verify the consistency of (rather than ignore) the STH with tree_size 150, since that may be a log server's attempt at forking. I think the monitor algorithm described in http://tools.ietf.org/html/rfc6962#section-5.3 sufficiently covers this case ("Fetch the current STH (Section 4.3). Repeat until the STH changes."), but perhaps the term "new STH" used later in the algorithm could be clarified to mean "STH you haven't seen before", to avoid it being interpreted it as "STH with an equal or larger tree_size than the most recent STH".
|
That's interesting... technically it shouldn't really happen with our logs, at least not over a window of that size, but Tom's response is insightful and pretty much on the money. Thanks for reporting, though. I'll look into what could have caused that. I've updated the issue summary as this is really a bug against the monitor code. |
Thanks for the input. We will patch the monitor accordingly and submit the patch set as usual. BTW Al, the log server imposed a similar behaviour last Friday, 07-03-14 GMT, but this time the tree size didn't even change. First time received STH $A: First time received STH $B (with a refreshed timestamp and no other changes): Received STH $A, again: Again - as Tom explained - this behaviour is acceptable according to the RFC but I'm eager to know why the pilot log server actually behaves this way :-) |
FYI, we used https the past week and didn't trigger this issue anymore. This does not necessarily render Bens ticket obsolete, of course. |
No description provided.
The text was updated successfully, but these errors were encountered: