Re: [Trans] STH Discipline & Security Considerations

[Richard Barnes <[e-mail]>]

On Fri, Mar 3, 2017 at 2:09 PM, Andrew Ayer <[e-mail]> wrote:

> On Fri, 3 Mar 2017 13:24:51 -0500
> Richard Barnes <[e-mail]> wrote:
>
> > # STH Discipline
> >
> > Either style of auditing also works better if logs have a notion of
> > "STH discipline", in the following sense:
> >
> > 1. The official state of the log comprises a sequence of STHs issued
> > at specified intervals.
> >
> > 2. For each certificate in the log, there is a single "canonical STH"
> > to which
> >    the log will produce an inclusion proof.
>
> To be clear, would there still be a way to get inclusion proofs to
> non-canonical STHs?  Clients wouldn't have to use them if they didn't
> want to.
>

I could go either way.  My preference would probably be to make it OPTIONAL
for a log to provide such proofs, because caching.  The client can always
just fetch the canonical proof and consistency.  (Maybe that needs to be a
new endpoint.)



> > Proofs to other STHs are
> > done by
> >    adding a consistency proof to the inclusion proof.
> >
> > This property makes things work more smoothly in both auditing models:
> >
> > - If the browser is willing to cache STHs, this tells the browser
> > exactly which
> >   STHs it needs to cache in order to validate all inclusion proofs.
> >
> > - Everything is more cacheable, since there's only one inclusion
> > proof per certificate, and a limited set of heads among which
> > consistency needs to be
> >   calculated.
> >
> > - Cacheability means that the fetches of inclusion proofs get greater
> > privacy
> >   benefit from caching, since they depend only on the certificate,
> > not the STH
> >   that the client is using.  Likewise for consistency proofs, because
> > of the reduced variety.
> >
> > >From a protocol point of view, I haven't done a thorough evaluation
> > >of the
> > document, but there are at least a few things you would want to make
> > this model
> > work:
> >
> > - Prose that articulates the above bounds on logs / inclusion
> > proofs / STHs. Probably a notion of "STH issuance frequency" parallel
> > to MMD.
> >
> > - A field in an SCT that indicates the canonical STH for the
> > certificate in question.  Possibly a serial number in STH that SCTs
> > could refer to.
>
> Is this necessary?  Why not define the canonical STH as the first STH
> issued after the SCT (based on timestamp)?
>

The reason you want an indicator in the SCT is so that you know which STH
to ask for, e.g., if you're fetching a consistency proof.  Otherwise, you
have to scan around for the right one.



> > - An API endpoint for fetching STHs in the official sequence (in
> > addition to the current one, which is the only option right now).
>
> +1. I think any privacy-preserving auditing mechanism will need such an
> endpoint so that STHs can be reliably distributed to clients.
>

Thanks for the feedback!

--Richard



>
> Regards,
> Andrew
>