Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis)

[Linus Nordberg <[e-mail]>]

Andrew Ayer <[e-mail]> wrote
Fri, 5 May 2017 10:09:10 -0700:

> On Thu, 04 May 2017 20:58:16 +0000
> Nick Sullivan <[e-mail]> 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?

I'm probably missing something crucial here but if it's not auditable,
what use does it have?

It seems to me that you're transcending towards a log of STHs, which I
wouldn't mind thinking about but probably not as an ad-hoc addon to a
new get-sths API.

For the record, I'd like to express hesitance about adding an STH
history API until I understand the problem better, with apologies for
not being fully up to speed at the moment.