get-sth inconsistent in nimbus2024 ?

[Bret McGee]

Apologies if this is off-topic, but I noticed an issue with nimbus202x.

In short, I am polling every minute to get-sth and when there are more than 4096 leaves available (compared to my last download) I trigger a download in blocks of 256 until I receive them all).  This is done in blocks of 4096 leaves.

However, sometimes the requests fail because less than 256 are returned.

Interestingly the get-sth calls are not consistent.  See a snapshot below for calls to nimbus2024

These are in reverse chronological order.  You can see that some calls offer a much older timestamp with a smaller tree size.

This is very nasty behaviour and I suspect it's down to load balanced servers or caches not being synchronized properly.

Has anyone seen this before?

[Matthew McPherrin]

Serving inconsistent STH is not good.  You should share your findings on the ct-policy list, https://groups.google.com/a/chromium.org/g/ct-policy

--
You received this message because you are subscribed to the Google Groups "crt.sh" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crtsh+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/crtsh/7d38fe69-2efc-4d70-b9bc-e43168ae869en%40googlegroups.com.

[Bret McGee]

Thanks Matthew, I'll see about putting that all into a neater table so it's clearer to see and send it on at some point tomorrow to the group you shared.

STH is "consistent" in that it's not offering a different hash for the same tree size, but it's offering old STHs.  All signatures verify correctly.

Many thanks.

[Matthew McPherrin]

Personally, I would consider "going backwards" and serving an old STH to be an inconsistency.

[Bret McGee]

Agreed.  It certainly breaks the principle of least surprise...!