Re: [Trans] How to redact an entry

Phillip Hallam-Baker <ietf@hallambaker.com> Wed, 16 November 2016 01:01 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B88F1295E0 for <trans@ietfa.amsl.com>; Tue, 15 Nov 2016 17:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgnCZ8LDf073 for <trans@ietfa.amsl.com>; Tue, 15 Nov 2016 17:01:18 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96CE129592 for <trans@ietf.org>; Tue, 15 Nov 2016 17:01:17 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id a197so204755622wmd.0 for <trans@ietf.org>; Tue, 15 Nov 2016 17:01:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dT1E1odGOjs/YqJKoAdQpDVUWNB7JKftEA3Rt+mAEWg=; b=nhH0HZBPhGD97vJx/CiZZQL74gysG3KJOzvI2dMMpW+YUYVM7F3DKg1i0jpSA18vYb sjBWoSNbknEtXlSAJZbK+jiIbUAObRpwARvCVRvLWrD5Ed6e4N3hrxSaG8rEvf0LrNyu ddEGeNKdjrk12RhqXEER0zNniLaYqu8UoBnPkbQRl7WajqxAEkgPfRhCoLGUGnldGD7g 87nJpYguFh5tO69yVMIYZS0UFXDcdV2pwyi6COE++zk4a8dX9+fqAPmLZuMfzfcRe2ME d5MSMWtRGlNLDLmrcMVV0wtBgzvhceQFInFtO4zBsZSKDAWxDD48GvihrL9o6CsScEf2 fkWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dT1E1odGOjs/YqJKoAdQpDVUWNB7JKftEA3Rt+mAEWg=; b=heuZ+nAahEMfjFUyS3mHEjMLG41t08rGP1/vdjl9R6/GLvtU4ACLxP5lqL6NBwRhTW pjrM0tHR5NdYSIOBf6uZChXfJfSyzFgW3+GkrzA7K1QQODVR9E0pui0xMsSu4U/mUtOr lpJgL8ENXCcktWItoiKgaz+M2KB4Vm4Kt8PRIHQzzl6MCZi3WY0WokSx6ufLtUkKp1Jy LAGcshysaiJGjbQ0V+oANiYpIDZWfpnn83TG5edN7RbnJLjzOIR81qESAPkmixhj8omA vwwKzeXyr2LUhtpNusnbp3Bw9xUnvEtW1iSK6Ez7hSG2QN7gs+lrW9i6G09EVC/bviXM Uh5g==
X-Gm-Message-State: ABUngvfV2NPL4ng0B80FEyducDovcXMvbFFKG3YdJriZ37URqPUtc4WsMqgGa03crqkgkKy6ldgiVXWAHmGyVg==
X-Received: by 10.194.187.103 with SMTP id fr7mr96320wjc.99.1479258076340; Tue, 15 Nov 2016 17:01:16 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.3.41 with HTTP; Tue, 15 Nov 2016 17:01:15 -0800 (PST)
In-Reply-To: <CABrd9SSeePrsNq8ERjxpbEvUAdyb=yQOGAom0qh9SZMoP=nsMw@mail.gmail.com>
References: <CABrd9SSeePrsNq8ERjxpbEvUAdyb=yQOGAom0qh9SZMoP=nsMw@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Tue, 15 Nov 2016 20:01:15 -0500
X-Google-Sender-Auth: oRj9_--FoM94T2TBMwcFmkokAU0
Message-ID: <CAMm+LwiZUw+JpEanY5vkxGBOtdrs9HfYzp34cBtwDv34uJCjKw@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary="047d7bd6bc9c2bf3660541609ce7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/i9pDCesmxrLy5oePyRv9R5uOsmU>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] How to redact an entry
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 01:01:19 -0000

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.