Re: [Trans] Gossip: Unsticking a client caught with potential evidence of log misbehavior

[Ben Laurie <[e-mail]>]

On Tue, 20 Oct 2015 at 00:26 Tom Ritter <[e-mail]> wrote:

> Hi all,
>
> So as we're working through the Gossip draft we ran into a problem we're
> not really sure how to solve. The gist of it is that a client can wind
> up in a state where it has a piece of data that it is pretty suspicious
> of, and it might be evidence of log misbehavior - but it's also private
> data and it has no way to share it with the world.
>
> We have not addressed this in the -01 draft, it's an open question with no
> text currently.
>
> Here are some ways that situation can arise (not exhaustive, but the
> draft will have an exhaustive list):
>
> A client has a Cert+SCT and wants an inclusion proof. Every time it
> sends it up to the log (via an appropriately privacy-preserving
> mechanism, such as a DNS proxy), it gets the equivalent of a 500 error,
> even through other inclusion proof requests succeed.
>
> A client has an older STH and it wants a consistency proof to a newer
> STH that it can pollinate. But it gets an error on every request, even
> though other consistency proof requests succeed.
>
> A client knows a log has shut down, and it has the 'final STH'. It has
> an older STH and wants to resolve it to the final STH, but again - errors.
>
>
> We've been working off the assumption that some data would get out to
> auditors and the auditors would detect the misbehavior - but here the
> client has a piece of data that is privacy-sensitive, so it can't just
> broadcast it widely. But it also could be evidence of log misbehavior -
> and the fact that it gets other successful responses from the log makes
> it even more suspicious.
>
> What should it do?
>
> I've been talking about the possibility of an 'escape valve' where a
> client would release private information to an auditor-of-last-resort of
> its choosing (well, chosen by the developer of the client probably)
> after a sufficiently rigorous attempt to resolve it in a private
> manner... but that's not very satisfying. And it's even less satisfying
> to wave our hand and leave the criteria for releasing it undefined
> (because it ties so much into the algorithm for how to release data in
> any circumstance.)
>
> We even talked about UI/UX.  This is such a crazy and rare situation
> that there's no hope of explaining it to users.  It's also something
> disconnected from any browsing session, so it's not possible to put a
> link on an intersitial as Chrome has done. The closest analogy is
> bug/crash reporting, either active (Windows/Apple sometimes asks if you
> want to submit queued error reports) or general browser opt-in (I
> believe Chrome/Firefox have some mechanism where you 'share data with
> the company to make the experience better').
>

How about reporting it to the alleged origin? Presumably there's no privacy
issue there (the user visited the site already) ... the origin would then
have to do something with that report - I can imagine that browser vendors
would operate public endpoints for them to be forwarded to, for example.

Seems like the same kind of issue as HPKP reporting (see
https://tools.ietf.org/html/rfc7469#section-2.1.4).