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

[Tom Ritter <[e-mail]>]

On 21 October 2015 at 08:52, Linus Nordberg <[e-mail]> 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 =)

> 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/
;)

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


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