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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 08 June 2011 12:56 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 63E2A21F8466; Wed, 8 Jun 2011 05:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 5XFGnt0X6ge1; Wed, 8 Jun 2011 05:56:12 -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 CB57B21F8465; Wed, 8 Jun 2011 05:56:11 -0700 (PDT)
Received: by gxk19 with SMTP id 19so242872gxk.31 for <multiple recipients>; Wed, 08 Jun 2011 05:56:11 -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=4DKvSgqeqGU/20oCZl/vKyuSeqaNw/OyCxczAeSzsFI=; b=qRMpfes9zGNg28E/I1QH2y6T+uexpAy8V+veV9h80vm/4LaHyCqS1tAJ2E7VYIJx0S /ETNBV24J8ffW99fR/wuL45QKNkg3/3Hfjx5yn+33f8ksgX/cNSwx3NYl0OODln3Yqs9 AHeLQB0cRfkPzFAwEBf85qpiXKrFm+pFFgxmM=
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=D2MElVWPNwOzZXkZLYxyHEV15vKJc5+xXt54KynWpTLuf8/SXetcUnObwFa8YarBxG DLJMzkCcSBrCSxs0nQSaC2UOJsBp+Wuh3CORtHoL115a702fE9NTExY2uuaE0J9t/iuX 3oN9K+K5q4CtOD4miAN+U+skN/h4IrMFGqgiE=
MIME-Version: 1.0
Received: by 10.101.200.1 with SMTP id c1mr6093068anq.63.1307537771053; Wed, 08 Jun 2011 05:56:11 -0700 (PDT)
Received: by 10.100.41.5 with HTTP; Wed, 8 Jun 2011 05:56:10 -0700 (PDT)
In-Reply-To: <E1QUEVy-0002cB-JN@login01.fos.auckland.ac.nz>
References: <6B039F9F-B66E-41A3-894E-8F1996A87209@checkpoint.com> <E1QUEVy-0002cB-JN@login01.fos.auckland.ac.nz>
Date: Wed, 8 Jun 2011 08:56:10 -0400
Message-ID: <BANLkTikO4W_voMQkoo-gsXAYkMfi09GQyg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=0016e68deca85fc31c04a532dcf1
Cc: pkix@ietf.org, paul.hoffman@vpnc.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 12:56:13 -0000

First off, I think that people need to stop using the -gate suffix. Just
because a competitor decided that they would attempt to apply it does not
mean it is justified. That is an old game and a rather silly one in our
industry. The relevant cautionary text here being John 8:7.

What differentiates companies in our industry is not whether they are
breached, it is whether they give prompt, voluntary notice of breaches that
occur or not. The market leaders in the CA industry have a track record of
having done so.


As for CAA being a response to the Iranian attack, Ben, Rob and I developed
it a year earlier.

The point of proposals like CAA is not whether they are 'necessary' or not,
it is whether they mitigate risk. I have never seen a security control
involving a human element that is guaranteed to be operated with 100%
accuracy every time. So whenever there are humans involved I like to have
strength in depth.

There would be no problem here if browsers actually implemented revocation
checking either. But we have had that in PKIX specs for 15 years and it
still isn't deployed in hard fail mode. Which is rather sad when you
consider that about 70% of the complexity of PKI comes from the need for
revocation.