On 21 October 2015 at 08:52, Linus Nordberg <[email protected]> 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 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
