On Fri, May 19, 2017 at 08:45:00PM +0000, Nick Sullivan wrote:
> On Fri, May 19, 2017 at 10:44 AM Al Cutter <[email protected]> wrote:
> > but you later acknowledged that a get-sths API without some extra
> > sprinkles *somewhere* doesn't actually solve that problem because there's
> > nothing stopping a Log from going back and creating a few extra "old" STHs
> > to cover, say, a period when its signing infrastructure was down, which
> > it'll happily return to you when you call get-sths at a later date.
>
> This is prevented by requiring the get STHs endpoint to provide a
> consistent sequence of entries over time and making sure that auditors
> track it. Alternatively, the chaining idea also achieves this, and so does
> logging STHs as you suggest.
If you're already requiring auditors to remember what they've seen before,
why not just get them to remember the STHs they've seen, rather than having
to remember that they've seen an additive sequence of previous STHs and
verified that nothing's magically appeared?
I think the proposal to log STHs is a good one. It provides several advantages:
* it prevents the need to have a separate "enumerate all
prior STHs" (because you can get them all by walking the log);
* it naturally discourages a log from issuing huge numbers of STHs (for
tracking purposes) because it bloats the log, and is extremely visible;
* it provides cryptographic proof of malfeasance (attempted tracking)
if someone can provide an STH that isn't in the log;
* it provides cryptographic proof of blowing an MMD if the difference
between the STH timestamp in the logged entry and the first STH that
includes that entry are too far apart.
- Matt
--
"I'm a manager. I don't do maths."
-- Jeff Waugh, DebSIG
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
