Re: [Trans] How to redact an entry

On Fri, Feb 24, 2017 at 11:21 AM, Eran Messeri <eranm@google.com> wrote:
> Following up on this thread, after a few discussions about it in online &
> offline forums:
> - It is necessary to have the "Redaction reason" entry in the log to commit
> the log to the redaction of a particular entry and avoid allowing the log to
> present redacted/unredacted view at will.
> - A few have echoed Phillip's sentiment that once an entry is suppressed
> then the suppression reason can't be effectively audited for correctness.
> - There was a strong push-back against this mechanism on the basis that it
> weakens the basic properties we get from the Merkle tree right now.
> Potential problems: What if the "Redaction reason" entry itself was
> redacted?
> - A suggestion by Peter Bowen was to simply not serve the redacted entry:
> The only API method by which a suppressed entry can be obtain is
> 'get-entries', it's possible to return an error when the range specified
> includes a suppressed entry. That suffers from the same drawback of the log
> being able to selectively presenting redacted/unredacted view.

Another option would be to return something other than "leaf_input"
and "extra_data" in the object.  For example the log could return the
hash of the MerkleTreeLeaf that was there along with a reference to
the leaf that has the redaction reason entry.

> - An approach many see as superior is to reduce the chances of having
> entries with undesirable content in the log by restricting the certificates
> that may be logged (e.g. forbidding certificates with embedded images).
>
> Eran
>
> On Wed, Nov 16, 2016 at 6:20 AM, Phillip Hallam-Baker <ietf@hallambaker.com>
> wrote:
>>
>> 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.
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 6:48 AM, Ben Laurie <benl@google.com> wrote:
>>>
>>> On 16 November 2016 at 11:39, Paul Wouters <paul@nohats.ca> wrote:
>>> > On Wed, 16 Nov 2016, Ben Laurie wrote:
>>> >
>>> > (no hats on)
>>> >
>>> >> On 16 November 2016 at 03:46, 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?
>>> >>
>>> >>
>>> >> 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.
>>>
>>> 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.
>>
>>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>