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

[Eran Messeri <[e-mail]>]

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

On Tue, Oct 20, 2015 at 2:22 PM, Katriel Cohn-Gordon <[e-mail]>
wrote:

> On Tue, Oct 20, 2015 at 1:53 PM, Robin Wilton <[e-mail]> wrote:
>
>> If it’s not appropriate, under these circumstances, to forfeit some
>> degree of origin privacy by invoking at least one auditor, then I think we
>> need to consider how to mitigate the risk that the origin is a bad actor.
>
>
> ​The context for this attack is a colluding malicious CA and log server,
> right?​ If so, is CT even intended to handle a colluding website, CA and
> log server?
>
> (Incidentally, since a log server knows when it is releasing proof of
> cheating, I suppose malicious servers would generally opt to error instead
> of proving their misbehaviour.)
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>
>