[Trans] Gossip: Unsticking a client caught with potential evidence of log misbehavior

Tom Ritter <tom@ritter.vg> Mon, 19 October 2015 23:26 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33AE1B2EB9 for <trans@ietfa.amsl.com>; Mon, 19 Oct 2015 16:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
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 xuefxBbFFL6E for <trans@ietfa.amsl.com>; Mon, 19 Oct 2015 16:26:24 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 88E1E1B2EB0 for <trans@ietf.org>; Mon, 19 Oct 2015 16:26:24 -0700 (PDT)
Received: by qgem9 with SMTP id m9so609404qge.1 for <trans@ietf.org>; Mon, 19 Oct 2015 16:26:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=YJJ2fQZ3QhaJOF1VTjwdobZgyQk0T1nX2ZoTHsKyZUA=; b=Az1TEusqmndnzpsu3euQhTC1B/hJgG/TsPSUUTaF0QBagsnneezFDb6LqFWZ6eWWla KOqw1r/tMCSKMCqzoKprgn7PFjLV7I3QWejlAAxbds4ewi7KW+2v+cqAErAF2BXqOLlv V0pwHkpahz+C+aL5BgYgy5M1K6anOH1rUT4Ao=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=YJJ2fQZ3QhaJOF1VTjwdobZgyQk0T1nX2ZoTHsKyZUA=; b=BCvh+2mCDYtvk73gTN8IReEENt9izuMHaXtVUMIKyoE5iLQHUWn4Ak564rPpKOzlSm 3aXB5aUp7Ir34u6kfZt7Z2vK9C2w7wP/675N3CCzwWKKSbxZwz25AbIMUQFu4N+LJmaB E5DYcwXpXXTAnB7+XW7BdNt6vUBNj2+Iivc7w1bwoSK6Te3/WcrYtXQwNEo8joY9mHlx rkb/+JhDe1gCgxdGd0XZu2R4ax4PJkgHnrNuI6DlpKOiek94CEnpMHkZV5/I9lX3otVT YTDFSqkkFwEu2ZdBqxBn/m5KaMA7zJcwf+S+LAa7/qar1XbUc380eiFQoiiUugQRKVix 0PPw==
X-Gm-Message-State: ALoCoQmS10GJxdRAqHeydPDTr2+oPfnBY0nC+Eprd+SFwcWLJtR4e9WxA2ONgqncy4elUZU8pjuJ
X-Received: by 10.140.134.211 with SMTP id 202mr48717qhg.51.1445297183805; Mon, 19 Oct 2015 16:26:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.94.6 with HTTP; Mon, 19 Oct 2015 16:26:04 -0700 (PDT)
From: Tom Ritter <tom@ritter.vg>
Date: Mon, 19 Oct 2015 18:26:04 -0500
Message-ID: <CA+cU71m0wpnD1ZYOTtr=oW+1BjquFxyagtMt+wgCgC_PD0PE-g@mail.gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/6Vh8xWFtSZ_GAS1JRXFJt-rFBb8>
Subject: [Trans] Gossip: Unsticking a client caught with potential evidence of log misbehavior
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 19 Oct 2015 23:26:26 -0000

Hi all,

So as we're working through the Gossip draft we ran into a problem we're
not really sure how to solve. The gist of it is that a client can wind
up in a state where it has a piece of data that it is pretty suspicious
of, and it might be evidence of log misbehavior - but it's also private
data and it has no way to share it with the world.

We have not addressed this in the -01 draft, it's an open question with no
text currently.

Here are some ways that situation can arise (not exhaustive, but the
draft will have an exhaustive list):

A client has a Cert+SCT and wants an inclusion proof. Every time it
sends it up to the log (via an appropriately privacy-preserving
mechanism, such as a DNS proxy), it gets the equivalent of a 500 error,
even through other inclusion proof requests succeed.

A client has an older STH and it wants a consistency proof to a newer
STH that it can pollinate. But it gets an error on every request, even
though other consistency proof requests succeed.

A client knows a log has shut down, and it has the 'final STH'. It has
an older STH and wants to resolve it to the final STH, but again - errors.


We've been working off the assumption that some data would get out to
auditors and the auditors would detect the misbehavior - but here the
client has a piece of data that is privacy-sensitive, so it can't just
broadcast it widely. But it also could be evidence of log misbehavior -
and the fact that it gets other successful responses from the log makes
it even more suspicious.

What should it do?

I've been talking about the possibility of an 'escape valve' where a
client would release private information to an auditor-of-last-resort of
its choosing (well, chosen by the developer of the client probably)
after a sufficiently rigorous attempt to resolve it in a private
manner... but that's not very satisfying. And it's even less satisfying
to wave our hand and leave the criteria for releasing it undefined
(because it ties so much into the algorithm for how to release data in
any circumstance.)

We even talked about UI/UX.  This is such a crazy and rare situation
that there's no hope of explaining it to users.  It's also something
disconnected from any browsing session, so it's not possible to put a
link on an intersitial as Chrome has done. The closest analogy is
bug/crash reporting, either active (Windows/Apple sometimes asks if you
want to submit queued error reports) or general browser opt-in (I
believe Chrome/Firefox have some mechanism where you 'share data with
the company to make the experience better').

-tom