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

On Thu, 22 Oct 2015 at 03:16 Tom Ritter <tom@ritter.vg> wrote:

> On 21 October 2015 at 08:52, Linus Nordberg <linus@nordu.net> wrote:
> > | > - 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.
>
> I am less concerned about this aspect of delegation. A server can
> always share data out of band width a third party.  And they can even
> delegate it to a third party without us knowing.  So enabling a
> mechanism that makes it _easy_ to delegate it does not worry me as
> much as it does you =)
>

I totally agree.

>
> > Impractical since the browser would have to know which domain that
> > example.com has delegated its SCT Feedback to.
>
> This is an engineering problem I don't see a neat solution to. So
> obviously the solution is a new HTTP header! SCT-Feedback:
>
> https://uncle-neds-discount-hanggliding-and-sct-feedback-correlator.website/google.com/
> ;)
>

Quite so.

> Susceptible of blocking since it cannot be performed in the same TLS
> > stream as the ordinary https request.
>
> But this one does worry me very much.  We mention it down in
> https://tools.ietf.org/html/draft-ietf-trans-gossip-01#section-10.2.1
> and I'm hopeful we will get implementations that multiplex gossip
> traffic as much as they can so it is much more difficult to block.
>

It does seem like it is possible to make life quite tricky for attackers...

>
>
> > | > - 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".
>
> Yes.  The risk here is admittedly less than that of a SCT, but I do
> still worry about it.
> Would it solve the problem if we had an additional one-week grace
> period?  Where we say "You resolve older STHs into a fresh STH - but
> if you encounter an error trying to resolve a STH that is between 2
> and 3 weeks old, you pollinate it anyway?"
>
> What are the implications of that... So a log could refuse to resolve
> a consistency proof, and the client would pollinate it. A website
> (colluding with the log) could identify that client individually
> (because no one else would be pollinating that STH.)  Separately, if
> website A receives old-STH, and website B receives it as well, they
> can do some pretty reliable cross-origin linkage.  But they can't
> actually induce a client to pollinate old-STH without either the log's
> help (by refusing to resolve a consistency proof) or without blocking
> the consistency proof resolution.
>
> Are there more? That seems like it could be acceptable to me from a
> privacy POV... And it seems like it would solve the problem... I can't
> think of a way you receive (no-maliciously) an older-then-three-week
> STH.
>
> -tom
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>