Andrew Ayer <[email protected]> wrote Fri, 5 May 2017 10:09:10 -0700:
> 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? 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. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
