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

[Eran Messeri <[e-mail]>]

On Tue, Oct 20, 2015 at 4:22 PM, Tom Ritter <[e-mail]> wrote:

> On 20 October 2015 at 08:46, Eran Messeri <[e-mail]> wrote:
> > +1 for reporting it backed to the alleged origin - the problem Tom
> describes
> > is significant as the client would want to hold onto these suspicious
> pieces
> > of information until it is confident it has been reported, but has no
> way of
> > knowing if the report has been acknowledged by the 'genuine' origin.
> >
> > One option is to not prescribe when clients drop such pieces of
> information,
> > so clients are free to re-send it multiple times or even forever, until
> an
> > out-of-band signal (i.e. a client software update) is received to
> indicate
> > to the client that this information has been received and acted upon.
>
> So reporting it back to the origin is an appropriate solution for a
> subset of situations.  If I have an SCT+certificate I want to resolve
> to a STH, but can't, I can report it up to the origin via SCT
> Feedback.  We also (or will) have guidelines for submitting it
> multiple times, and ensuring that it's reported on a connection that
> 'looks okay' (we have some notes in 7.1.1)
>
> There are (at least) two cases that aren't covered by "report it to
> the origin". (Maybe more, but I can only think of two right now.)
>
> - The origin doesn't implement SCT Feedback.
>
 This is a hard one - if a domain operator isn't interested in learning
about attacks against their domain, can anything be done about that?
My suggestion for this case is to make it easy to delegate SCT Feedback -
so domain owners can allow other domains which operate SCT Feedback to
receive SCTs on their behalf. How does that sound?

> - The data I have is an older STH, which is not tied to any specific
> origin.
>
I think this case is less sensitive from a privacy perspective and so could
be gossiped with any servers that do implement SCT Feedback?

>
> -tom
>