Re: [TLS] [certid] fyi: paper on compelled, certificate creation attack and applicable appliance

Story Henry <henry.story@bblfish.net> Thu, 25 March 2010 20:58 UTC

Return-Path: <hjs@bblfish.net>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44683A6C1D for <tls@core3.amsl.com>; Thu, 25 Mar 2010 13:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.05
X-Spam-Level: **
X-Spam-Status: No, score=2.05 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_43=0.6, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fJeQOJwwIdv for <tls@core3.amsl.com>; Thu, 25 Mar 2010 13:58:33 -0700 (PDT)
Received: from bblfish.net (rust.entic.net [199.89.53.222]) by core3.amsl.com (Postfix) with ESMTP id 66DC73A67A3 for <tls@ietf.org>; Thu, 25 Mar 2010 13:58:33 -0700 (PDT)
Received: from dan75-8-88-181-10-216.fbx.proxad.net ([88.181.10.216] helo=bblfish.wistro) by bblfish.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <hjs@bblfish.net>) id 1Nuu8i-00026n-TC; Thu, 25 Mar 2010 13:58:53 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=windows-1252
From: Story Henry <henry.story@bblfish.net>
In-Reply-To: <4BABBA93.40207@fifthhorseman.net>
Date: Thu, 25 Mar 2010 21:58:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFD148C4-640F-4A52-BA4F-3BE7DA614636@bblfish.net>
References: <4BAA7F31.5050706@KingsMountain.com> <20100325041402.GA6222@eltex.net> <4BABA01E.7080808@extendedsubset.com> <4BABBA93.40207@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.1077)
Sender: hjs@bblfish.net
Cc: foaf-protocols@lists.foaf-project.org, Dan Kaminsky <Dan.Kaminsky@ioactive.com>, tls@ietf.org, =JeffH <Jeff.Hodges@KingsMountain.com>, ArkanoiD <ark@eltex.net>
Subject: Re: [TLS] [certid] fyi: paper on compelled, certificate creation attack and applicable appliance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2010 20:58:37 -0000

Context: the  recent publication "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL"

   http://files.cloudprivacy.net/ssl-mitm.pdf

On 25 Mar 2010, at 20:33, Daniel Kahn Gillmor wrote:

> On 03/25/2010 01:40 PM, Marsh Ray wrote:
>> The only reason that the world isn't up-in-arms about it is that 59% of
>> PCs are pwned by malware already, making the slightly more complicated
>> mitm attack unnecessary.
>> 
>> However, there are important uses of SSL/TLS other than end user web
>> browsers. These are probably better off with just the minimal number of
>> trusted roots on the clients. But if you're going to the trouble of
>> reconfiguring your clients anyway, why not just set up your own private CA?
> 
> Running your own X.509 CA works if your goal is only
> intra-organizational communication.  As soon as you want to federate
> communication with external organizations, running your own CA is
> insufficient with X.509, because the model only allows a single
> certifier per certificate.

Yes, this is a very important point made by Kaminsky in an interview last year
http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1360143,00.html

What is interesting for me is this last paragraph of the paper under discussion:

[[
The CA system is fundamentally broken, and must be overhauled. DNSSEC may 
play a significant role in solving this problem, or at least reducing the
number of entities who can be compelled to violate users’ trust.
]]

What would be possible, and I think Kaminsky is considering this line of
 thinking, is something that is logically similar to foaf+ssl 
( http://esw.w3.org/Foaf%2Bssl ) namely to put the CA cert (or signature) 
in the DNS record.

Let us start by an important philosophical distinction between sense and 
reference. The sense of a word is something like a dictionary definition 
of it, its referent is the the object. 

Applying this to DNS, let us say that the reference of a domain name is
a set of machines. But the sense of this is to be found in the DNS resource 
records. So if one can securely put the DNS public key (indirect) identifier 
in the records then the client can verify the certificate sent by the server
by comparing it with the DNS record.

Foaf+ssl works in a similar way to identify agents. Agents have URLs that 
refer to them, and the sense of this name is to be found in a document on the web.

So

 http://bblfish.net/#hjs

Refers to me, and the description about that is to be found in

 http://bblfish.net/

(note: of course those should be https urls)

In the document about me ( http://bblfish.net/ ) I publish a number of 
public keys. Any server I then connect to can ask me for my client 
certificate and on receiving it, find in the subject alternative name 
my WebId ( http://bblfish.net/#hjs ), dereference that and query the 
returned graph to check if I have the public key that was found in 
my certificate. Since the TLS connection was only possible because I 
had the private key of the public key found in the certificate, and 
verified at the WebId, we have authentication.

DNSSEC could use exactly the same procedure, just reversed to identify 
the server. Instead of using https URLs we use Domain Names, and the 
lookup is whatever the protocol for looking at DNS records is.

To prove this one would just need to adapt the proof presented in 
"FOAF+SSL: Creating a Web of Trust without Key Signing Parties" 

http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf

	Henry Story