Yeah, if you have collusion between the govt making the suppression order and the attacker (or they are the same)...
Problem is that otherwise a hostile party can make a DoS attack against the whole system... agh,,, On Tue, Nov 15, 2016 at 10:59 PM, Paul Wouters <[email protected]> wrote: > A suppression of a fake gmail.com cert in the logs so google will never > know a rogue cert was issued and used? > > Sent from my iPhone > > On Nov 16, 2016, at 12:54, Phillip Hallam-Baker <[email protected]> > wrote: > > That particular attack is certainly an issue for some linked notary logs. > The point of CT is to prevent insertion attacks, to ensure that only items > entered into the log are notarized. > > What is the harm you see being caused by suppression? Remember that a > party that has the actual data can still prove that it was enrolled. > > > On Tue, Nov 15, 2016 at 10:46 PM, Paul Wouters <[email protected]> wrote: > >> How can I as log consumer detect the difference between the log removing >> illegal content and the log being compelled by a government to hide a rogue >> certificate? >> >> Sent from my iPhone >> >> On Nov 16, 2016, at 10:01, Phillip Hallam-Baker <[email protected]> >> wrote: >> >> >> >> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie <[email protected]> wrote: >> >>> Eran asked me to briefly describe how redaction in a transparency log >>> would work. >>> >>> First, we introduce a new leaf type, "Redacted". The content of this >>> leaf is simply the hash of the original leaf, the entry number of the >>> redaction reason entry (see below) and a signature over the content by >>> the log key. >>> >>> Rather than hashing this entry, verifiers simply use the enclosed hash >>> to calculate the tree hash. >>> >>> Secondly, we introduce a second new leaf type, "Redaction reason". >>> This leaf contains two things: the entry number of the redacted entry >>> and a textual explanation of why it was redacted (possibly we need to >>> get a little more elaborate here, but perhaps the simplest thing to do >>> is to allow it to include URLs to point to any supporting material). >>> This leaf type would be hashed in the usual way. >>> >>> Observers of the log can verify that every redacted entry has a >>> corresponding redaction reason entry, and if not, can produce proof it >>> does not (this is why the redacted entry has to be signed directly). >>> >>> Note that the redacted entry could not include the entry number of the >>> redaction reason, if preferred, though that would force an observer of >>> that entry to download the whole log to verify the reason and also >>> would make proof of non-compliance bulky. :-) >>> >> >> I decided I had to do something of this sort in the Mesh notary log. It >> is probably a good idea to do it as a matter of course. >> >> Lets consider the general case for a moment, what happens if someone puts >> some child pornography into the log. Obviously you can't publish it or you >> go to jail. So you have to take it out which breaks the log. >> >> So either you have to devise a scheme that you are certain cannot be used >> to publish abusive material or you have to have a way to suppress it >> either. I think the second approach is better. >> >> >> Of course putting bad stuff in a Trans log would be a lot more effort >> than putting it into the blockchain or the like. But don't think it is >> impossible. I have a few attacks that are worrying enough not to want to >> share in public. The sort of thing that has Special Branch making house >> calls. >> >> So I would hash the received data values before enrolling the hash in the >> notary log as a matter of course. >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> >> >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
