Re: [pkix] [Technical Errata Reported] RFC6844 (4988)

Phillip Hallam-Baker <philliph@comodo.com> Mon, 03 April 2017 22:04 UTC

Return-Path: <philliph@comodo.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2591293FF for <pkix@ietfa.amsl.com>; Mon, 3 Apr 2017 15:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mJVG8js8XOQ for <pkix@ietfa.amsl.com>; Mon, 3 Apr 2017 15:03:56 -0700 (PDT)
Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD651243F6 for <pkix@ietf.org>; Mon, 3 Apr 2017 15:03:55 -0700 (PDT)
Received: (korumail 7512 invoked from network); 3 Apr 2017 22:03:54 -0000
Received: from unknown (HELO clofcgmail2.cl.office.comodo.net) () by 0 with SMTP; 3 Apr 2017 22:03:53 -0000
Received: (qmail 9791 invoked by uid 1012); 3 Apr 2017 22:03:53 -0000
Received: from pool-100-0-244-109.bstnma.fios.verizon.net (HELO VooDoo) (100.0.244.109) (smtp-auth username philliph, mechanism login) by clofcgmail2.cl.office.comodo.net (qpsmtpd/0.84/v0.84-169-ga857589) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Mon, 03 Apr 2017 18:03:53 -0400
From: Phillip Hallam-Baker <philliph@comodo.com>
To: 'RFC Errata System' <rfc-editor@rfc-editor.org>, rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, kent@bbn.com, stefan@aaa-sec.com
Cc: phill@hallambaker.com, pkix@ietf.org
References: <20170403205009.2A72BB801B0@rfc-editor.org>
In-Reply-To: <20170403205009.2A72BB801B0@rfc-editor.org>
Date: Mon, 3 Apr 2017 18:03:51 -0400
Message-ID: <004501d2acc6$2e9e8b10$8bdba130$@comodo.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJBjNZhvWZBAzWalcLPpt1G9biGp6DWckrg
X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.6
X-KORUMAIL-Result: Clean (Content eval: 0.000000 points)
X-KORUMAIL-Reason:
X-KORUMAIL-QueueId: 7490-1491257033-757485
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/mGGAfIzbMdiygM8WkH0s02I2cg4>
Subject: Re: [pkix] [Technical Errata Reported] RFC6844 (4988)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 22:04:01 -0000

Damn! And as Rob pointed out, a typo

   o  If A(X) is not null, and CAA(A(X)), then R(X) =
      CAA(A(X)), otherwise

So do I submit a second errata?

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] 
Sent: Monday, April 3, 2017 4:50 PM
To: philliph@comodo.com; rob.stradling@comodo.com; Kathleen.Moriarty.ietf@gmail.com; ekr@rtfm.com; kent@bbn.com; stefan@aaa-sec.com
Cc: phill@hallambaker.com; pkix@ietf.org; rfc-editor@rfc-editor.org
Subject: [Technical Errata Reported] RFC6844 (4988)

The following errata report has been submitted for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4988

--------------------------------------
Type: Technical
Reported by: Phillip Hallam-Baker <phill@hallambaker.com>

Section: 4

Original Text
-------------
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

Corrected Text
--------------
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME 
   alias record chain specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)), then R(X) =
      CAA(X), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

  Thus, when a search at node X returns a CNAME record, the CA will
  follow the CNAME record to its target. If the target label contains a
  CAA record, it is returned. otherwise, the CA continues the search at
  the parent of node X. 

  Note that the search does not include the parent of a target of a
  CNAME record (except when the CNAME points back to its own path).

  If the target of a CNAME record is itself a CNAME record, the CA MAY
  follow it or MAY ignore it. In either case, the search continues at
  the parent of the label containing the initial CNAME.

  Processing for DNAME is exactly the same as for CNAME. Note that since
  DNAME records are implemented by creating the corresponding CNAME
  records on the fly, it is only necessary for DNAME records to appear
  on the wire for purposes of DNSSEC.
   

Notes
-----
This is a fuller response to the issue raised in 4515. Note that the algorithm stated in RFC6844 was the algorithm intended at the time it was written. Subsequent implementation has shown that the approach described here is preferable.

This is a breaking change and thus the intended disposition is Hold for Document Update. The principle purpose of this errata is to provide a stable reference for the benefit of CABForum which publishes certificate validation guidelines that mandate CAA. This in turn will avoid the need for work being proposed to provide a full solution to the problem to have to address backwards compatibility with an approach now seen as undesirable.

The issue arises because CNAME records are commonly used for the purpose of host delegation and name delegation and no distinction is made between the two. Nor does the use of DNAME records allow such distinction be made in practice. Further, the limitation that CNAME be the only record in a zone is a liability. The original algorithm was designed to provide an administrative convenience for the name delegation case. Subsequent discussion with CDNs has shown that the host delegation use is sufficiently widespread for this approach to be unsatisfactory.

After discussion in the LAMPS working group, a new approach is being considered which allows both sets of requirements to be met using an extended search algorithm. Until this is done, it is best that implementations do not perform the recursive portion.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6844 (draft-ietf-pkix-caa-15)
--------------------------------------
Title               : DNS Certification Authority Authorization (CAA) Resource Record
Publication Date    : January 2013
Author(s)           : P. Hallam-Baker, R. Stradling
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG