IETF Logo Mail Archive

Re: [Trans] Gossiping in CT

Tao Effect <contact@taoeffect.com> Sat, 27 September 2014 23:10 UTC

Return-Path: <contact@taoeffect.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 77B541A005A for <trans@ietfa.amsl.com>; Sat, 27 Sep 2014 16:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 KRe3Y4qpV0Uc for <trans@ietfa.amsl.com>; Sat, 27 Sep 2014 16:10:37 -0700 (PDT)
Received: from homiemail-a6.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 913811A0055 for <trans@ietf.org>; Sat, 27 Sep 2014 16:10:36 -0700 (PDT)
Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 5DF6659806C; Sat, 27 Sep 2014 16:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=fGz5mo3epI1AO/Oqw Jxry0NVZGw=; b=j2NFbgiDogHRdfztK5w+vwi1YT5rNkg5jfXclP4ulqymEtZqL iy8TZrKNI4NaP4DDYVuglhaD2RG/zRL/6sJQX1EMIGLk1Bwzzd5P0D1xu9iVT8J7 l1TT0HRuXwaDQR1ZDRj0lUQ0MXzLZE7QgntGa9xdd7Qhhf+o2lyKwuTnkU=
Received: from [192.168.42.78] (50-0-138-93.dsl.dynamic.sonic.net [50.0.138.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 0D4F3598021; Sat, 27 Sep 2014 16:10:35 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_E0C97BE8-CE13-46D2-808B-DB981122D261"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.1 (f76fd85)
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <878ul5tcby.fsf@nordberg.se>
Date: Sat, 27 Sep 2014 16:10:35 -0700
X-Mao-Original-Outgoing-Id: 433552234.943105-b3af4ddc10f61bee0bf966ffba2b10f1
Message-Id: <10C2C42B-5C59-47DD-817C-52B3CB1322DF@taoeffect.com>
References: <878ul5tcby.fsf@nordberg.se>
To: Linus Nordberg <linus@nordu.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4DaKrnEDjOlzizf0p6NvUuG6Vos
Cc: trans@ietf.org
Subject: Re: [Trans] Gossiping in CT
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: <http://www.ietf.org/mail-archive/web/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: Sat, 27 Sep 2014 23:10:42 -0000

Dear Linus,

Paul Wouters brought up the idea of sharing certs on [metzdowd], and I guess that's the same thing as gossiping SCTs, right?

I think that could actually be very useful for detecting a MITM, here's my reply to him there:

http://www.metzdowd.com/pipermail/cryptography/2014-September/023037.html

> The more information shared, the better detection we seem to get. But
> sharing information have privacy implications. It seems to me that
> sharing STH's is much less problematic than sharing SCT's.

Why do you think sharing SCTs is problematic, and what privacy implications does it pose?

If the SCTs are shared over an encrypted connection, only the server, the client, and the potential MITM will know about them.

Any time a cert changes, the client would tell the server about that change over the established TLS connection.

When MITM leaves, the server would find out that a fraudulent cert had been generated for their website, and could then identify the CA responsible.

Kind regards,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

v2.23.0 | Report a Bug | By Email