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

[Tom Ritter <[e-mail]>]

On 22 October 2015 at 17:48, Daniel Kahn Gillmor <[e-mail]> wrote:
> On Thu 2015-10-22 06:23:35 -0400, Ben Laurie wrote:
>> On Thu, 22 Oct 2015 at 03:16 Tom Ritter <[e-mail]> wrote:
>>> On 21 October 2015 at 08:52, Linus Nordberg <[e-mail]> wrote:
>>> > 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.
>
> I can't tell how much people are kidding around here -- i see Tom's
> winky emoticon, at least.
>
> But which version of the site should get to declare where the delegation
> should happen -- the version that has the bogus cert with SCTs from the
> colluding logs, or the "real" version?

The header should not persist, it should be required to be present on
every response to keep the delegation occuring.  So assume the fake
server sets it, and you give some SCT feedback to the delegated
attacker.  Later when you visit the site, and no longer see the
header, you give SCTs to the real site.  I don't think this changes
the threat model, as we assume the attacker cannot forever-middle a
user.

I tend to like HTTP headers, but I do recognize there's a ton of them.

On 22 October 2015 at 05:25, Ben Laurie <[e-mail]> wrote:
> On Thu, 22 Oct 2015 at 03:16 Tom Ritter <[e-mail]> wrote:
>>
>> I can't
>> think of a way you receive (no-maliciously) an older-then-three-week
>> STH.
>
> You can end up with one if you receive a fresh one and then go to sleep for
> 4 weeks...

That's true. It seems different from the client receiving a 4-week old
STH via the network though.

If you start up and have a 4-week old STH in your store - you can
presume that you recived it when it was fresh. And if you cannot
resolve with a consistency proof - it seems 'safer' to me in some way.
If you receive a 4-week old STH from a site, I might assume they're
trying to load me with a tracking STH.

But in general we're back in the bucket of "What do I do with this."
Do we share it with websites via STH Pollination even though it can
enable very reliable cross-origin linkage?  I don't think we can,
because (besides the privacy issue) we don't want to require the
website to resolve consistency proofs nor do we want the website to
give 4-week old STHs to other clients.  Do we share it with an
auditor-of-last-resort (after failing to resolve a consistency proof),
thinking that the privacy implications of a STH are much lesser than
the near-certainly of cross-origin linkage?

-tom