Date: Fri, 3 Mar 2017 11:09:50 -0800
From: Andrew Ayer <agwa@andrewayer.name>
To: Richard Barnes <rlb@ipv.sx>
Message-Id: <20170303110950.b04152416b71a5873b74fa37@andrewayer.name>
In-Reply-To: <CAL02cgSr_G6HdS7f28cgBE4G_DAhnz6ios2EsTGEx==t6ONOZw@mail.gmail.com>
References: <CAL02cgSr_G6HdS7f28cgBE4G_DAhnz6ios2EsTGEx==t6ONOZw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/jbJ2al5NWUwx6SuZRlGMDWueSlQ>
Cc: Trans <trans@ietf.org>
Subject: Re: [Trans] STH Discipline & Security Considerations
Precedence: list

On Fri, 3 Mar 2017 13:24:51 -0500
Richard Barnes <rlb@ipv.sx> 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.

> 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)?

> - 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.

Regards,
Andrew