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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 02 June 2011 13:46 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 7E26DE06E3; Thu, 2 Jun 2011 06:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level:
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
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 vYIPQhYy6uF7; Thu, 2 Jun 2011 06:46:02 -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 3A5DEE0692; Thu, 2 Jun 2011 06:46:02 -0700 (PDT)
Received: by gxk19 with SMTP id 19so430784gxk.31 for <multiple recipients>; Thu, 02 Jun 2011 06:46:01 -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=prU8UQTtRwAzI3BDjsYM/Ug4VIvCMuieUEGebFRtEHY=; b=TMT5ipF/YktJ+C0csbz/P5iFCZY97f4lJtv3OSb2g+ETO/UAWNwCm0Qm5Hu1SFWW4R iAd9aeMkOKCO5PIqBrSgKbgQK7V30zJkip3hklge6vw0BTb2a1L3tISvBUtf0fu4lMpZ YDBvH8JCi59GuS6EZFPJKiV27jfagCySD4e9E=
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=xZOJmv0f8jYzU9Wnj+EDu4V1XwhGYwLkTrOQxLoSFiayi1G8oB+q9hQAeGiAsXRQNB zkCf4IJhrR+syeNgOoRQI++gdsAluwco8LfkccVpSqmZNd+afp08Ed2gWV/4D62Gmt8D FgHMAvH2UFf2rUnlObrCjIjLG7gIiIvyxPrtI=
MIME-Version: 1.0
Received: by 10.101.11.14 with SMTP id o14mr461549ani.88.1307022358736; Thu, 02 Jun 2011 06:45:58 -0700 (PDT)
Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 06:45:58 -0700 (PDT)
In-Reply-To: <7A11CFD1-F0AA-4CA4-8542-CA7998D2FBEF@checkpoint.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>
Date: Thu, 02 Jun 2011 09:45:58 -0400
Message-ID: <BANLkTi=SPK6j5CgAFhF04SLP8dd3DP0Mow@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary="0016e68fcec467efc004a4badb85"
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 13:46:03 -0000

That is not quite right.

First off, measurement of the failure rate of CAs is rather difficult
because we only actually know the failure rate for CAs that self-report. It
is not zero but it is close enough to being zero that people can work
themselves up into a lather about it.

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.


But more importantly, an RA does not have issuing power by definition. Only
a CA can issue certificates because that is the definition of a CA. The
intention of CAA is that it be enforced by the CA so that an RA cannot issue
a non compliant cert either.

One area where I could see a possible use case for extending CAA would be to
enable better RA management controls. For example the vast majority of the
'RAs' identified in the EFF study are actually intermediate roots assigned
to RAs at educational institutions. Such RAs only have general issuing
powers in a minority of circumstances.

We had some discussion of this after my SAAG presentation.

Here is the issue: some of these controls will be technical and some will be
policy. Some of these controls will be the type of thing IETF likes to work
on and some will not. That is why we have CABForum.

And then another question that naturally comes up is how much of this we
should do in phase 1 and whether we should attempt to do everything at once
or to do the lowest of the low hanging fruit first, gain some experience and
then add in features to support additional use cases.


The final point made is that some CAs may not want to support CAA. I can't
see why this would be so unless either:

1) The technology is deficient (something PKIX might fix).
2) They really want to be able to issue fraudulent certificates.
3) They resist change for the sake of it.
4) It is not yet an IETF standard

Now I have no idea which of the above might apply if any. But the only way
to find out is going to be to deploy.

This is still a worthwhile exercise if the only effect is to identify CAs
that wish to issue fraudulent certificates. The IETF does not have the power
to police such CAs but others do.


On Thu, Jun 2, 2011 at 12:10 AM, Yoav Nir <ynir@checkpoint.com> wrote:

>
> On Jun 2, 2011, at 3:12 AM, Michael D'Errico wrote:
>
> > Paul Hoffman wrote:
> >>
> >> I support the PKIX WG adopting as a work item (wording taken from the
> CAA draft's text) "DNS Resource Records that allow a DNS domain name holder
> to specify the certificate signing certificate(s) authorized to issue
> certificates for that domain".
> >
> > I haven't read the draft, but from the quote it appears that
> > this could improve the weakest part of TLS (as it is used
> > today in browsers) where any of the hundreds of preinstalled
> > root CAs is trusted to issue a certificate to any possible
> > domain name.
>
> I'm not opposed to this draft, but I don't think it solves this problem.
> The issue is not even the dozens of pre-installed root CAs, but that those
> root CAs can have many many affiliates, whether they're sub-CAs or
> registration authorities.
>
> The two famous attacks of the last two years have not been about Verisign
> or Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the
> "Verisign trust network" but not Verisign itself. In the recent case it was
> a small Italian RA. In both cases the problem was an affiliate with not
> quite best practices that caused the mis-issue.
>
> CAA works if all root CAs and affiliates follow it. That's hundreds or
> thousands of entities. Any one of them that fails to comply might ignore the
> CAA record.
>
> PHB says that having the CAA record may aid in assigning blame, and thus
> perhaps at some point, liability. Remains to be seen, but at least in the
> short term, CAA is not a panacea.
>
> That's why I believe that the DANE record that is aimed at relying parties
> is a necessary complement to this work. I know I've said the opposite on the
> DANE list, but I've changed my mind since then.
>
> Yoav
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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