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

Tao Effect <contact@taoeffect.com> Fri, 27 March 2015 19:43 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 41DF21A924A for <trans@ietfa.amsl.com>; Fri, 27 Mar 2015 12:43:17 -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 e3c5_ccL_3RA for <trans@ietfa.amsl.com>; Fri, 27 Mar 2015 12:43:09 -0700 (PDT)
Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1C1A8AEC for <trans@ietf.org>; Fri, 27 Mar 2015 12:43:09 -0700 (PDT)
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 294003BC06E; Fri, 27 Mar 2015 12:43:09 -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=ecL0DHqBpSdjQKlsj cHrVYKbJlM=; b=kGhLBUsizOzUHrMcmxcemkRPpmc7MUhJgljaO/X7Ofpord1wQ SMpP2bHTzqC3Z11LdKG2OKE31SUNoQR/2+eb90CP/6ap7rfjbJCvzAdSdCYdeeOE F7O8IyPcG6h36yHHJd0Z0+UXtwnj/kog7rorbD2+0cbyFG5XZFWz39CRCg=
Received: from [192.168.1.8] (50-0-163-72.dsl.dynamic.fusionbroadband.com [50.0.163.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 6C8C43BC06B; Fri, 27 Mar 2015 12:43:08 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_4251E6E5-D73C-4F0E-B34F-1207C0B1F8F0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.5b6
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <alpine.LRH.2.11.1503271517430.14223@ns0.nohats.ca>
Date: Fri, 27 Mar 2015 12:43:08 -0700
X-Mao-Original-Outgoing-Id: 449178187.767967-e57e3ff50a9255fa52544751566765a1
Message-Id: <EAFF927A-E95B-4D5E-A631-E7209725AF18@taoeffect.com>
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> <alpine.LRH.2.11.1503271517430.14223@ns0.nohats.ca>
To: "trans@ietf.org" <trans@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/7Ryj--bx822vqI7-5YZqO26N1rU>
Cc: Paul Wouters <paul@nohats.ca>, Tom Ritter <tom@ritter.vg>, Dmitry Belyavsky <beldmit@gmail.com>
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:43:17 -0000

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

That is my intention as soon as I am clear on one more question, prompted by something Dmitry just pointed out.

>> 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.

I am realizing that this may or may not happen, depending on which part of the TLS handshake these exchanges occur.

To illustrate:

A = server's real certificate
B = malicious MITM certificate

T1. Client receives A.
T2. Client receives B, sends back A.
T3. MITM pretends to leave, sends A. Client sends B.

At T3, if B is handled by MITM _outside and before_ the channel is encrypted by A, then the MITM can prevent the server from seeing B.

So, my question is: does your document properly take that into account and state that the data sent in 3.1.3 *must* be sent after a fully encrypted TLS connection has been established?

Scanning through it, this distinction doesn't seem to be mentioned.

Thanks,
Greg

P.S. FYI Paul, any time I CC your email I get a bounced "Undelivered Mail" response:

Final-Recipient: rfc822; cypherpunks@nohats.ca
Original-Recipient: rfc822;paul@cypherpunks.ca
Action: failed
Status: 5.1.1
Remote-MTA: dns; 193.110.157.102
Diagnostic-Code: smtp; 550 5.1.1 <cypherpunks@nohats.ca>ca>: Recipient address
   rejected: User unknown in local recipient table

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

On Mar 27, 2015, at 12:21 PM, Paul Wouters <paul@nohats.ca> wrote:

> 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
> 
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans