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

[Linus Nordberg <[e-mail]>]

Eran Messeri <[e-mail]> wrote
Tue, 20 Oct 2015 16:32:28 +0100:

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

Scary because we want the end user to trust that the same-origin
principle is indeed followed if they're going to play along with SCT
Feedback. Opening up for delegation sounds like bad news wrt this.

Impractical since the browser would have to know which domain that
example.com has delegated its SCT Feedback to.

Susceptible of blocking since it cannot be performed in the same TLS
stream as the ordinary https request.


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

We have STH Pollination for STH's but only if the STH is fresh, defined
in the draft as no older than 14 days. I think Tom means that "older"
implies "not fresh".