On Thu, 04 May 2017 20:58:16 +0000
Nick Sullivan <[email protected]> wrote:
> By consistent I mean that if a sequence of STHs such as (A, B, C) are
> presented on day 1, that a different sequence is not presented on day
> 2 (A, C) or (A, D, B, C).
The PR doesn't currently say the log must retain and return all STHs
it has ever signed. That should be added. Such language, plus the
existing chronological ordering requirement, plus the requirement that
STH timestamps be unique ("Each subsequent timestamp MUST be more
recent than the timestamp of the previous update") should ensure
consistency, right?
> Rob's language works in term of chronological order.
>
> STH pollination could be a way to support auditing this, but I don't
> think it's sufficiently robust as currently defined. To prevent STHs
> from going missing, or for new STHs to appear after the fact, STHs
> should be exchanged along with metadata indicating the previous and
> (if it exists yet) the next STH in the tree.
To be an effective auditing mechanism, this information needs to be
signed by the log. Otherwise, a monitor could lie about what it has
seen. Perhaps the STH could contain the timestamp of the previous
STH. If it did, I believe that STH pollination would be sufficient for
detecting STHs that go missing or appear after the fact.
That said, is there a compelling security need for this to be
auditable?
Regards,
Andrew
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
