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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 02 June 2011 16:31 UTC

Return-Path: <hallam@gmail.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 3BF1EE07FC; Thu, 2 Jun 2011 09:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.554
X-Spam-Level:
X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 HD5Nc-FXcVkN; Thu, 2 Jun 2011 09:31:18 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80BBDE07FA; Thu, 2 Jun 2011 09:31:15 -0700 (PDT)
Received: by gxk19 with SMTP id 19so515766gxk.31 for <multiple recipients>; Thu, 02 Jun 2011 09:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d3H1o1MfWU+6RcBf8CWGxD6qvH6V0IkUT3snbqlwYyI=; b=N32MUR3BOUl4OhXzElbn2wL9zWCKXXFF6igVeYkiiER5fZ1kjfes7kTlys2xfQYjGS 7wS/RO3esjrANTvAMjyBcC/EBQxv0BNdoIpAY4IA9WsyNJOZ0FT4DCaK4cVzAOwSRSXp SBYRywXMHeGwg44Z4D9BhkuUGQIb8dnQg/Bcs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=szE0GcwzrvDGP22jEkpvht7JN3bDzsXG+FBNO33WkrJ/fbd/J8fTrSV7f/5Vyp2d2w mlEQ4EWbjEOcvfkq1DCvu4DUKZyyY2oTQKtHPXGcVx/zbgMIwX4A9FGKMAjZwYZF6f97 Mt5D9VfVtDsV+7nRb1gX+ciEIR7mah0HqusfQ=
MIME-Version: 1.0
Received: by 10.101.74.10 with SMTP id b10mr590618anl.107.1307032273119; Thu, 02 Jun 2011 09:31:13 -0700 (PDT)
Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 09:31:13 -0700 (PDT)
In-Reply-To: <4DE7B529.9040206@extendedsubset.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> <4DE7B529.9040206@extendedsubset.com>
Date: Thu, 2 Jun 2011 12:31:13 -0400
Message-ID: <BANLkTimPHF61PqsecLxUsmkKbTgY8Jia1w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: multipart/alternative; boundary=0016368e1f855969d804a4bd2a38
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:31:20 -0000

On Thu, Jun 2, 2011 at 12:07 PM, Marsh Ray <marsh@extendedsubset.com> wrote:

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

I hear you.

But lets be realistic here, we are currently actually doing worse for non
browser security.

The weakest link in the TLS protocol is actually the end user who is for
some bizarre reason expected to be looking for padlock icons and green bars
and know when to look for which one.

This is even more problematic when applying TLS to Web services as there
isn't even a user to make the decision and no real idea of what should do
that instead.


CAA is not going to solve every problem associated with trust on the
Internet and CA infrastructure. Nor is TLS and nor is strict security. But I
do think that a combination of those three ideas can make a major step
forward.

That is why CAA is designed to be arbitrarily extensible with a tag-value
format even though there are only two property tags currently defined. I
really like the work that Paypal and Jeff Hodges have been doing and would
like to have a way to eventually bring CAA into alignment there.


But for the moment we have to avoid 'crossing the streams' as Stephen F. put
it to me.

Lets work on the part of the problem that we can while the Web Security folk
work on understanding the complexities of what strict security involves.




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

Yes and that may well end up motivating a mechanism to allow for protocol
specific path properties so that enterprises can have separate CAs
authorized for separate protocols.

Web Services security is a big part of what I am interested in supporting
here. We went into the Web Services world with certain interests promoting
UDDI as the central directory to make it all work. So now we have a protocol
stack predicated on the existence of a directory with no directory to work
with.


I have some ideas there, but again, that would be crossing the streams at
this point. I think the way to get traction there will be to propose a Web
Service application with some pretty severe security requirements and make
that the test application for a framework designed to 'do it right'.


-- 
Website: http://hallambaker.com/