[messaging] Transparency for E2E encrypted messaging at a centralized service

[Trevor Perrin]

On Fri, Mar 28, 2014 at 5:09 AM, Thomas Ristenpart <rist at cs.wisc.edu> wrote:
> I haven't been following through all the details of this exchange, so
> sorry if this was brought up already, but you might want to check out
> this paper:
> http://www.internetsociety.org/doc/enhanced-certificate-transparency-and-end-end-encrypted-mail


This proposes 2 merkle trees: using one as an authenticated
dictionary, while also entering the (certificate,
hash-root-of-auth-dictionary) pairs into a CT-style append-only merkle
tree.

The claimed advantage of this over an authenticated dictionary alone
is that adding the CT-style tree enables efficient proofs that one log
is an "extension" of another.

It's unclear to me why this is useful.  The paper argues:

"""
Linearity: It is vital that the log is a single linear record. If the
log maintainer can create different versions of the log to show to
different users, the security is lost. Linearity is maintained in two
ways. Firstly, whenever a user interacts with the log, it requests
proof that the current snapshot is an extension of the previously
cached snapshot.[...] Second, gossip protocols [30] can be used to
disseminate values of the log. This means that users of the log (that
is, client browsers) need to have a way to exchange with other users
the value of the hash of the log that they have received. At any time,
a user can request proof that the snapshot currently offered by the
log is an extension of a previous snapshot received through direct
communication with other users.
"""

I agree that we want to prevent "abuse of the change mechanism to make
temporary changes shown only to a subset of relying parties", as Ben
puts it [1].

But I don't see why this requires complicated "proofs of extension".
In Ben's "Revocation Transparency", he proposes the simpler idea of
entering the root-hashes of the authenticated dictionary, alone, into
an append-only log [1,2].

I'll argue for an even simpler idea: clients maintain a
collision-resistant hash over all authenticated-dictionary
root-hashes.  Clients can compare this hash.  If it differs, the log
must have provided different root-hashes.  If these root hashes are
signed, this can be used to show log misbehavior.

Is that sufficient?  Am I missing something?


Trevor


[1] http://www.links.org/?p=1272
[2] http://sump2.links.org/files/RevocationTransparency.pdf