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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 25 March 2010 19:34 UTC

Return-Path: <dkg@fifthhorseman.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 8C6B13A6928 for <tls@core3.amsl.com>; Thu, 25 Mar 2010 12:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.842
X-Spam-Level:
X-Spam-Status: No, score=0.842 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, URI_NOVOWEL=0.5]
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 EEq8l+Mpx4PK for <tls@core3.amsl.com>; Thu, 25 Mar 2010 12:34:23 -0700 (PDT)
Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by core3.amsl.com (Postfix) with SMTP id 77C843A6D6E for <tls@ietf.org>; Thu, 25 Mar 2010 12:33:40 -0700 (PDT)
Received: (qmail 36660 invoked from network); 25 Mar 2010 19:34:01 -0000
Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay00.pair.com with SMTP; 25 Mar 2010 19:34:01 -0000
X-pair-Authenticated: 216.254.116.241
Message-ID: <4BABBA93.40207@fifthhorseman.net>
Date: Thu, 25 Mar 2010 15:33:39 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)
MIME-Version: 1.0
To: Marsh Ray <marsh@extendedsubset.com>
References: <4BAA7F31.5050706@KingsMountain.com> <20100325041402.GA6222@eltex.net> <4BABA01E.7080808@extendedsubset.com>
In-Reply-To: <4BABA01E.7080808@extendedsubset.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9; url=http://fifthhorseman.net/dkg.gpg
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCCB8B471EFF01EC624BBF5C0"
Cc: ArkanoiD <ark@eltex.net>, tls@ietf.org, =JeffH <Jeff.Hodges@KingsMountain.com>
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 19:34:24 -0000

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.

>> There is nothing we can do besides examining chain of trust manually
>> and watching for certificate changes.
> 
> We could implement our protocols such that the remote peer is required
> to satisfy multiple chains of trust.
> 
> When a chain is only as strong as its weakest link, it's best to have
> several of them (in a redundant configuration).

This is possible today using out-of-band OpenPGP certification, which
permits multiple certifiers per certificate.

 http://web.monkeysphere.info/

We currently have it working bidirectionally for openssh and
unidirectionally (firefox browsers can authenticate servers) for https.
 More is coming soon, and feedback is welcome, particularly from folks
who are interested in TLS mechanisms.

>> The TOFU technology described
>> there is quite obvious, i always wondered why ssh has it and browsers
>> do not.
> 
> In theory, SSH's approach is inferior to SSL's PKI. In practice it's not
> inferior only to the extent that the user is good at scrutinizing the
> new keys he gets presented.
> 
> If you want that behavior in a web browser, just delete all your trusted
> root certs and add a persistent explicit trust whenever you see a cert
> the first time. (I have tried this in Firefox)

I believe you can do this system-wide with firefox and other
mozilla-based browsers by removing the nssckbi shared library
(/usr/lib/nss/libnssckbi.so on debian, a .dll someplace on windows),
which provides the pre-defined list of root CAs.

	--dkg