Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item

Marsh Ray <marsh@extendedsubset.com> Wed, 08 June 2011 16:58 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFA611E8124; Wed, 8 Jun 2011 09:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap08nTqyKK-e; Wed, 8 Jun 2011 09:58:33 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id B205E11E8116; Wed, 8 Jun 2011 09:58:33 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1QUM5M-000CiO-Tx; Wed, 08 Jun 2011 16:58:29 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DC712606D; Wed, 8 Jun 2011 16:58:25 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/rzfy4xvQ9qWn+YkqaFIScB8s43rtL+Ns=
Message-ID: <4DEFAA31.4040709@extendedsubset.com>
Date: Wed, 08 Jun 2011 11:58:25 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <E1QUDSr-00081X-EE@login01.fos.auckland.ac.nz> <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com>
In-Reply-To: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "pkix@ietf.org" <pkix@ietf.org>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [pkix] Proposing CAA as PKIX Working Group Item
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 08 Jun 2011 16:58:34 -0000

On 06/08/2011 03:37 AM, Yoav Nir wrote:
>
> What did Comodo fail to do?

If this question is seriously being asked by one as knowledgeable as 
Yoav :-), it suggests to me that the problem is being way over-thinked. 
So forgive me, I'm just going to re-state this bluntly:

The entire value proposition of PKI is based on the trusted root CAs 
refusing to issue fraudulent certs and in this case Comodo, a trusted 
root, failed to refuse to issue certain fraudulent certs.

> The RA is handing contact with the customer, so it's their job to
> make sure that the customer is in fact the owner of the domain name
> in the certificate request.

These legal agreements and auditing procedures only amount to one thing: 
after the victim has been (possibly irreparably) harmed by the issuance 
of a fraudulent certificate, then some legal entity is in a technical 
violation of contract with some other legal entity.

In this case, I've heard of no serious repurcussions other than the loss 
of image to the CA and the RAs. Certainly significant for Comodo, but 
most of the press coverage doesn't even mention the names of the hacked RAs.

Is the CA suing any hacked RA for breach of contract? Are they even 
terminating their agreements?

Are browser vendors removing any root CAs or blacklisting any sub-CAs 
due to this?

What are the costs paid for this debacle as perceived by others with the 
authority to cause the immediate issuance of certs?  Most importantly, 
will these costs always be perceived higher than the immediate gain of a 
corrupt transaction? This is not to suggest any corruption in this case 
of course, but it is surely not going unnoticed for the future that the 
CA, the RAs, and the individuals involved all demonstrated effective 
deniability.

This seems like a good test case to either support or refute the 
arguments of those who claim that policies, auditing, and legal 
agreements between CAs/RAs/subCAs are an effective way to produce strong 
security.

- Marsh