[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
- [Trans] Gossip: Unsticking a client caught with p… Tom Ritter
- Re: [Trans] Gossip: Unsticking a client caught wi… Ben Laurie
- Re: [Trans] Gossip: Unsticking a client caught wi… Robin Wilton
- Re: [Trans] Gossip: Unsticking a client caught wi… Katriel Cohn-Gordon
- Re: [Trans] Gossip: Unsticking a client caught wi… Eran Messeri
- Re: [Trans] Gossip: Unsticking a client caught wi… Tom Ritter
- Re: [Trans] Gossip: Unsticking a client caught wi… Eran Messeri
- Re: [Trans] Gossip: Unsticking a client caught wi… Ben Laurie
- Re: [Trans] Gossip: Unsticking a client caught wi… Linus Nordberg
- Re: [Trans] Gossip: Unsticking a client caught wi… Tom Ritter
- Re: [Trans] Gossip: Unsticking a client caught wi… Ben Laurie
- Re: [Trans] Gossip: Unsticking a client caught wi… Ben Laurie
- Re: [Trans] Gossip: Unsticking a client caught wi… Daniel Kahn Gillmor
- Re: [Trans] Gossip: Unsticking a client caught wi… Tom Ritter
- Re: [Trans] Gossip: Unsticking a client caught wi… Ben Laurie
- Re: [Trans] Gossip: Unsticking a client caught wi… Ben Laurie