Re: [Trans] How to redact an entry

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 <paul@nohats.ca> 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 <ietf@hallambaker.com>
> 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 <paul@nohats.ca> 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 <ietf@hallambaker.com>
>> wrote:
>>
>>
>>
>> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie <benl@google.com> 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
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>>
>