IETF Logo Mail Archive

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

Katriel Cohn-Gordon <me@katriel.co.uk> Tue, 20 October 2015 13:22 UTC

Return-Path: <katrielalex@gmail.com>
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 A37451A895B for <trans@ietfa.amsl.com>; Tue, 20 Oct 2015 06:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 g-WsUpkwwCH8 for <trans@ietfa.amsl.com>; Tue, 20 Oct 2015 06:22:43 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 9193F1A8953 for <trans@ietf.org>; Tue, 20 Oct 2015 06:22:42 -0700 (PDT)
Received: by lfaz124 with SMTP id z124so5487294lfa.1 for <trans@ietf.org>; Tue, 20 Oct 2015 06:22:40 -0700 (PDT)
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:content-type; bh=OZZb/JZBA0pk84crmK1LGaq/cp1zOCQqmz+6qvS6CVs=; b=H37FG8k+Qnyh6TgT/MYf3Hwhx7rdm66mMAYOiad8l8zsgUOjBFZwspt/CkTpBr2VfE 5utDaB5XMck9DnZzCg9rx1l8IoHCpcgB5+X77I1hTGU8XcWdGw29MNdRlFtZ9/tzhKIS 6mhzFqfX3xZmZ4PPY9Uirnkg0DeL+vZioC6NQCAa/B3BHR8SjMzUW8qqBW9gl2IEmD25 7Ls3EOhh5QxwXS/BUAkYvLJPtT+6FvQsuo8HFiBZVfjnE/JCpBA/p5jk7fT03YcDG/3s 0MWqhnHOZSLiV42vq9LHWlhxRafmaCArFPPbedq/yZK4Hx/b4k7Z/5FXL0us+/mBLJO+ pYlw==
X-Received: by 10.25.21.149 with SMTP id 21mr1211592lfv.61.1445347360749; Tue, 20 Oct 2015 06:22:40 -0700 (PDT)
MIME-Version: 1.0
Sender: katrielalex@gmail.com
Received: by 10.25.17.169 with HTTP; Tue, 20 Oct 2015 06:22:11 -0700 (PDT)
In-Reply-To: <E1812BE0-BD94-4050-95DB-C0483303AFF2@isoc.org>
References: <CA+cU71m0wpnD1ZYOTtr=oW+1BjquFxyagtMt+wgCgC_PD0PE-g@mail.gmail.com> <CABrd9SQd2RETKQWe9-_KCHufAWjBhs2k008vEz-5cyM_gbY4Qw@mail.gmail.com> <E1812BE0-BD94-4050-95DB-C0483303AFF2@isoc.org>
From: Katriel Cohn-Gordon <me@katriel.co.uk>
Date: Tue, 20 Oct 2015 14:22:11 +0100
X-Google-Sender-Auth: X9qcQ0jtxBDgIwlMOhHslF85jt4
Message-ID: <CABEqWMC=pJUMEn8DxxTn6VTBs9hpayC-ZVUwcGdvg=PEw-Q=Rg@mail.gmail.com>
To: Robin Wilton <wilton@isoc.org>
Content-Type: multipart/alternative; boundary="001a113f215603bf71052289282b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/hgR2PrK-nSRLVkUvsg2knFBiZhY>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [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: Tue, 20 Oct 2015 13:22:44 -0000

On Tue, Oct 20, 2015 at 1:53 PM, Robin Wilton <wilton@isoc.org> wrote:

> If it’s not appropriate, under these circumstances, to forfeit some degree
> of origin privacy by invoking at least one auditor, then I think we need to
> consider how to mitigate the risk that the origin is a bad actor.


​The context for this attack is a colluding malicious CA and log server,
right?​ If so, is CT even intended to handle a colluding website, CA and
log server?

(Incidentally, since a log server knows when it is releasing proof of
cheating, I suppose malicious servers would generally opt to error instead
of proving their misbehaviour.)

v2.23.0 | Report a Bug | By Email