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

[Robin Wilton <[e-mail]>]

A couple of thoughts in line...

On 20 Oct 2015, at 09:58, Ben Laurie <[e-mail]> wrote:

> 
> 
> 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.

This seems like an appropriate and privacy-preserving first step. The question then would be how to act on the various possible responses from the origin.

For instance, if the origin appears to take no action, and the symptom persists, that might be a suitable trigger for the “escape valve” Tom describes - i.e. reporting to a pre-specified auditor.

I think we need to bear in mind that the ultimate goal here is better behaviour through transparency. If it’s not appropriate, under these circumstances, to forfeit some degree of origin privacy by invoking at least one auditor, then I think we need to consider how to mitigate the risk that the origin is a bad actor.

> 
> Seems like the same kind of issue as HPKP reporting (see https://tools.ietf.org/html/rfc7469#section-2.1.4).
> 
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans