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

[Eran Messeri <[e-mail]>]

As it has been pointed out to me, the STH history API, even with the
proposed changes of adding a sequence number to issued STHs, or requiring
an STH refers to a previous STH, would not prevent backdating of STHs in a
meaningful way - see explanation below.

Because of that, I'm not sure it'll add anything to have this API - and if
we do add it, it should be an optional one.

Note that the threat I’m focusing on is detection of MMD breach: Where the
log hasn’t incorporated an entry corresponding to an issued SCT for more
than the MMD, _and a monitor could feasibly observe evidence of it_.

Here’s why, I think, adding references to past STHs wouldn’t improve the
situation:

Currently, clients cannot prove that a log has misbehaved, by serving an
STH that’s more than an MMD old. A client can claim that at a given time
the log has served it an STH that’s MMD + delta hours old, but cannot prove
it.

Additionally, close monitoring of a log can identify an MMD breach, but
only until 2*MMD - (some delta, marked d in the diagram) time has passed:
[image: MMD breach detection.png]
(Note in this diagram STH1 is on a tree that does not yet contain the SCT;
Only STH2 is).

Because the RFC requires an incorporation within the MMD, yet allows
serving an STH that’s up to MMD old, a log could incorporate an SCT within
the MMD but it would only be evident after more than MMD of the submission
time has passed - or it could backdate inclusion by backdating issuance of
an STH that includes the entry[0].

AFAICT requiring that STHs refers to previous ones does not change that in
any way - it does not prevent any backdating that’s now possible, nor does
it make it easier for a client to detect backdating:
* When a cunning log realises that it will fail to incorporate a pending
entry for longer than the MMD, it can immediately generate a back-dated STH
that shows it was included within the MMD, and an “innocent looking” STH
(timestamped ‘now’), that refers to the back-dated STH.
* A failure by the log to provide an STH in the “chain” of STHs (should
STHs include reference to previous ones) is equivalent to a failure by the
log to provide an STH that proves an inclusion of a particular entry: In
both cases the evidence would be STHs surrounding the entry that was not
incorporated.
* If a monitor has observed an STH that’s more than MMD old and does not
include an entry for a particular SCT, this is evidence enough for
misbehaviour.

So my concrete suggestion is then to not add get-sths entirely or make it
an optional API (because a log can only use it to incriminate itself, not
prove that it behaved).

[0] Note that backdating of selective submissions is not possible either
with or without back-references in STHs: A single submission that hasn’t
been incorporated cannot be retroactively incorporated, once the MMD has
passed, if other entries have been incorporated.



On Tue, May 9, 2017 at 12:08 AM, Linus Nordberg <[e-mail]> wrote:

> 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.
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>