Re: [Trans] Question regarding new gossip protocols [Was: Certificate transparency on blockchains]

Paul Wouters <paul@nohats.ca> Fri, 27 March 2015 19:21 UTC

Return-Path: <paul@nohats.ca>
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 06AE21A90DF for <trans@ietfa.amsl.com>; Fri, 27 Mar 2015 12:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] 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 Vb5RYrfQDjVF for <trans@ietfa.amsl.com>; Fri, 27 Mar 2015 12:21:22 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3445F1A90DA for <trans@ietf.org>; Fri, 27 Mar 2015 12:21:22 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lDChr2JjwzJsN for <trans@ietf.org>; Fri, 27 Mar 2015 20:21:16 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NGu1Lh6o0vyx for <trans@ietf.org>; Fri, 27 Mar 2015 20:21:15 +0100 (CET)
Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP for <trans@ietf.org>; Fri, 27 Mar 2015 20:21:15 +0100 (CET)
Received: by ns0.nohats.ca (Postfix, from userid 500) id 2355C3F7F0; Fri, 27 Mar 2015 15:21:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 1C4F03F58D; Fri, 27 Mar 2015 15:21:15 -0400 (EDT)
Date: Fri, 27 Mar 2015 15:21:15 -0400
From: Paul Wouters <paul@nohats.ca>
To: "trans@ietf.org" <trans@ietf.org>
cc: "trans@ietf.org" <trans@ietf.org>
In-Reply-To: <CADqLbz+8br-F3CJEgTj8K3HmaGdNKfjCSeDtWrDmySmohhjXkw@mail.gmail.com>
Message-ID: <alpine.LRH.2.11.1503271517430.14223@ns0.nohats.ca>
References: <007F2B41-C78E-4332-8206-7E4CB27A638B@kinostudios.com> <alpine.LFD.2.10.1503252231110.16175@bofh.nohats.ca> <2A773227-61C8-4196-8AFF-EC288A8AF150@kinostudios.com> <CA+cU71=7G5ZJMx3Vy+gXN00JpB61_6C+DLQRyCS=Hcq3vLR-Sg@mail.gmail.com> <CE157D3A-079C-4B09-B138-C21FD9D1FB03@taoeffect.com> <BAD439C7-60C8-44D4-89F9-AC6E5613A5EA@taoeffect.com> <CADqLbz+8br-F3CJEgTj8K3HmaGdNKfjCSeDtWrDmySmohhjXkw@mail.gmail.com>
User-Agent: Alpine 2.11 (LRH 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/R-LYmtYGye6fd-J175NwPsNb7mM>
Subject: Re: [Trans] Question regarding new gossip protocols [Was: Certificate transparency on blockchains]
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: Fri, 27 Mar 2015 19:21:23 -0000

On Fri, 27 Mar 2015, Dmitry Belyavsky wrote:

>       The document does say that clients MUST send the certificate chain back to servers, and that's good, because if that's
>       the case, shouldn't that be enough on its own for servers to detect that a MITM attack occurred (after the MITM
>       leaves)?
> 
> If that is so, it seems like a point worth highlighting in the document. It would completely address our concerns about CT's
> ability to detect MITM attacks post-facto.

It is.

> I suspect that a smart enough attacker will be able to send native certificates back to server instead of the ones he sent to client. Or
> am I missing something?

If the attacker fools the client with certificates, it is those
certificates that the client wil send back to the server once
the attacker is gone. It does not matter what the attacker do.

The attacker can forever keep sending whatever certificates
to the server. Once they are no longer attacker the client,
the client will note a different (the real!) certificate
of the server and send its previous (attacker's) certificate
to the server.

Perhaps this can be reflected in an update on the okturtles blog.

Paul