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

Marsh Ray <marsh@extendedsubset.com> Thu, 02 June 2011 16:07 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 F1408E07F9; Thu, 2 Jun 2011 09:07:11 -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 Xmx-gJq8w1Xz; Thu, 2 Jun 2011 09:07:11 -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 57CABE07CC; Thu, 2 Jun 2011 09:07:11 -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 1QSAQP-0004oW-76; Thu, 02 Jun 2011 16:07:09 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB72E606D; Thu, 2 Jun 2011 16:07:06 +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: U2FsdGVkX18ZaeEObNEyW+qN1tQpVBHZRJYsUTihz8k=
Message-ID: <4DE7B529.9040206@extendedsubset.com>
Date: Thu, 02 Jun 2011 11:07:05 -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: Phillip Hallam-Baker <hallam@gmail.com>
References: <BANLkTi=XZWwT0585uAuBmiUJr6eBjfgWmQ@mail.gmail.com> <C9FFF697.21E29%stefan@aaa-sec.com> <BANLkTiktoc+3t-rPgwRtx60UrrDy=vz0bg@mail.gmail.com> <p06240814ca0c32f70867@192.168.1.12> <44C530E6-3EF1-491C-9FC8-89BE12DB4ED5@vpnc.org> <p0624081bca0c624c205a@192.168.1.12> <BANLkTim-LEYNdn4f5-keRQLO+7FhfYXdwg@mail.gmail.com> <C26E1DE3-E036-45D1-B074-DEA4F2254D7C@vpnc.org> <4DE6D575.2000808@pobox.com> <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.com> <BANLkTi=SPK6j5CgAFhF04SLP8dd3DP0Mow@mail.gmail.com>
In-Reply-To: <BANLkTi=SPK6j5CgAFhF04SLP8dd3DP0Mow@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "pkix@ietf.org" <pkix@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, TLS Mailing List <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: Thu, 02 Jun 2011 16:07:12 -0000

On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote:
>
> At the end of the day buffer over-run exploits will still trump any
> deficiencies in the CA infrastructure. But those don't have people
> running round suggesting urgent remedies because they are too common to
> bear notice. CAs and RAs are definitely not the weakest link in the
> chain here. Anyone claiming that is either grandstanding or has failed
> to pay attention.

Well that depends entirely on the chain in question doesn't it?

Not everything that uses TLS or certificates is an unpatched web browser 
with Adobe plugins operated by an ignorant user for the purpose of 
securing nothing particularly important.

Over time it becomes increasingly difficult for _any_ distributed 
application to run over ports other than TCP 443 due to the growth of 
egress filtering. So stuff is bundled in with web traffic that may, in 
fact, be implemented for high security requirements.

Perhaps a solution is to implement your own application-specific trust 
root that doesn't rely on the current profusion of CAs. But as an 
application developer I can attest to the fact that it's difficult to 
use standard platform TLS libraries without also trusting everything in 
the system root store, too. Some sites will insist on using their own 
in-house CAs too, which is fine, but it's further pressure on everything 
else to integrate/be vulnerable with the browser trust model.

The net security world has changed dramatically over the last couple of 
years. We have to move past this 
broken-browser-as-least-common-denominator mentality.

- Marsh