Subject: [Trans] How to redact an entry

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Nov 2016 19:49:18 +0000

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. :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Nov 2016 20:01:15 -0500

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2016 12:46:42 +0900

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-masked]> wrote:
> 
> 
> 
> ​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-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Nov 2016 22:54:16 -0500

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-masked]> 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
>
> ​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.
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2016 12:59:00 +0900

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-masked]> 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.
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Nov 2016 23:09:56 -0500

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-masked]> wrote:

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Nov 2016 11:16:47 +0000

> illegal content and the log being compelled by a government to hide a rogue

Court orders are court orders. That issue is not in the log's domain.

> I decided I had to do something of this sort in the Mesh notary log. It is
> 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.
>
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Nov 2016 11:22:48 +0000

> Court orders are court orders. That issue is not in the log's domain.

BTW, anyone who sees the actual cert would presumably verify it, find
the entry is redacted, and publish the cert (or decide they were also
bound by the order cited in the redaction reason and not publish it
:-).

We could say, for example, that a cert whose entry has been redacted
MUST NOT be used further.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2016 06:39:11 -0500 (EST)

On Wed, 16 Nov 2016, Ben Laurie wrote:

(no hats on)

> Court orders are court orders. That issue is not in the log's domain.

It was an example. the core isuse is, how can a consumer determine the
log censored itself with a valid reason, versus an attack, compromise,
having been compelled, or for financial gain or any other invalid reason?

Using a hash of a removed cert won't allow anyone to verify the reason
for removal. And clearly the content cannot remain their either. It's
a catch22.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Nov 2016 11:48:19 +0000

> for removal. And clearly the content cannot remain their either. It's

This is why the redaction reason entry exists, so that there _is_
something to reason about. If you (a consumer) are unconvinced by the
reason, well, there are public fora where you can voice your concerns.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Nov 2016 09:20:03 -0500

Lets break this down.

In what way is suppression of a previously enrolled certificate different
to not enrolling the certificate at all?

The only ones I can see is that it means that 1) the CA is off the hook,
they fulfilled their duties and 2) the fact that suppression has occurred
is visible.

CT relies on there being some feedback mechanism to detect unenrolled
certs, the same would apply to suppressed certs.

So let us imagine that a government coerces a CA to issue a bogus cert and
then coerces a notary to suppress it. What next?

Well first off anyone who has a copy of that cert taken from the repository
before the suppression is going to hard look at it. So the chance of people
being aware of the suppression and working out the reason for it is
essentially 99%.

A person formerly very senior in NSA told me that the governing paradigm
post Snowden was 'NOBUS': Nobody but us. Sure they might want to perform
this type of attack if they think they can get away with it but they won't
do things that are liable to get caught.