Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

Ryan Sleevi <ryan-ietf@sleevi.com> Sat, 03 February 2018 00:39 UTC

Return-Path: <ryan-ietf@sleevi.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27494120726 for <spasm@ietfa.amsl.com>; Fri, 2 Feb 2018 16:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com
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 L2LAxIivypIV for <spasm@ietfa.amsl.com>; Fri, 2 Feb 2018 16:39:42 -0800 (PST)
Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1F21200C1 for <spasm@ietf.org>; Fri, 2 Feb 2018 16:39:42 -0800 (PST)
Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 5238830002B26 for <spasm@ietf.org>; Fri, 2 Feb 2018 16:39:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=VCVz3YFoxGUX5leEaUanaW7OD+I=; b= fdAbJIvGslMMJS6NNkgzeryUui06gofTwFiWcs2ZB3ct1VdN3Mx8VTf0Ep6ZJx3M 0r7uD7VECtERiITKLGP1KKaedhx33NIuZX+5iwZWSrsKD10B/xaWxTneadCYKmSe KltogmzbGdd17UWEzw6l5ygyN24ZmpIE7Rf8xwKFoIs=
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 3933830002B25 for <spasm@ietf.org>; Fri, 2 Feb 2018 16:39:42 -0800 (PST)
Received: by mail-io0-f179.google.com with SMTP id f34so24746171ioi.13 for <spasm@ietf.org>; Fri, 02 Feb 2018 16:39:42 -0800 (PST)
X-Gm-Message-State: APf1xPDYOH5kihmjHNm6UY3qQigKd25yXjiU+p2M2PSUkRv9MVV7PhJ+ FQk5ORmdD/iwVN6DweVgDv6RBa0B9lXzU/xkFM4=
X-Google-Smtp-Source: AH8x2246Pf6xcjCGEaAYqqAVtwXi0CC2ND17Rt+zOSguajouhpx4aIHL8NUNiQ8miFR86Uy2bLhlFNJ52MK+SsDHVE0=
X-Received: by 10.107.129.12 with SMTP id c12mr282820iod.303.1517618381575; Fri, 02 Feb 2018 16:39:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.37.202 with HTTP; Fri, 2 Feb 2018 16:39:41 -0800 (PST)
In-Reply-To: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Fri, 2 Feb 2018 19:39:41 -0500
X-Gmail-Original-Message-ID: <CAErg=HFibyNDfzo5RC7D06dhzw_Y7KLmsgpden7rHxnx2tEcag@mail.gmail.com>
Message-ID: <CAErg=HFibyNDfzo5RC7D06dhzw_Y7KLmsgpden7rHxnx2tEcag@mail.gmail.com>
To: Corey Bonnell <CBonnell@trustwave.com>
Cc: "spasm@ietf.org" <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f64e689dcb8056444103e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/eeNLRN0QNoMFGSoKCcZm539j_bA>
Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Feb 2018 00:39:45 -0000

On Fri, Jan 12, 2018 at 4:41 PM, Corey Bonnell <CBonnell@trustwave.com>
wrote:

> Hello,
>
> I believe that there are several ambiguities in RFC 6844 in regard to
> processing CAA resource record sets that do not contain "issue" records.
>
>
>
> Section 3 of RFC 6844 (http://www.rfcreader.com/#rfc6844_line196) defines
> the "issue" property tag to authorize "the holder of the domain name
> <Issuer Domain Name> or a party acting under the explicit authority of the
> holder of that domain name to issue certificates for the domain in which
> the property is published". Based on my interpretation, the definition
> given here is suggesting that CAA issue restriction processing is done
> regardless of whether or not there is an "issue" record(s) present to
> specify the set of permitted Issuer Domain Names. In other words, the lack
> of "issue" records in a CAA resource record set indicates that no CA may
> issue for that domain, since no CA has been authorized to issue.
>
>
>
> However, section 5.2 (http://www.rfcreader.com/#rfc6844_line447) defines
> the "issue" property tag to "request that certificate issuers perform CAA
> issue restriction processing for the domain and to grant authorization to
> specific certificate issuers". Based on this definition, it sounds as if
> CAA issue restriction processing is "opt-in". In other words, the absence
> of "issue" records in a CAA record set indicate that any CA may issue for
> that domain (since there was no "opt-in" into CAA restriction processing).
>
>
>
> Section 4 (http://www.rfcreader.com/#rfc6844_line288) states that,
> "before issuing a certificate, a compliant CA MUST check for publication of
> a relevant CAA Resource Record set." Unfortunately, the term "relevant" is
> not defined by the RFC, which, compounded with the ambiguity highlighted
> above in regard to the definition of the "issue" property tag in sections 3
> and 5.2, leads to ambiguity in the handling following scenarios:
>
>
>
> - A CAA resource record set consisting solely of unknown non-critical
> property tags (including misspellings of "issue", such as "iisue", etc.)
>
> - A CAA resource record set consisting solely of "iodef" property tags
>
> - A CAA resource record set that contains both of the above
>
>
>
> For each of these cases above, it is unclear which of the following three
> actions a CA should take:
>
> - Fail issuance (since the CAA resource record set did not authorize any
> CA to issue, given the definition of the "issue" property tag in Section 3)
>
> - Continue the tree-climbing search for records (since the resource record
> sets above could conceivably be considered as "not relevant")
>
> - Allow issuance (since the resource record sets above could conceivably
> be considered as "relevant" and any CA may issue, given the definition of
> the "issue" property tag in section 5.2)
>
>
>
> At Trustwave, we have taken the conservative approach and will not issue
> certificates if we encounter CAA resource record sets matching the
> descriptions of the three above. However, given that we may be overly
> restrictive by doing this, as well as for a desire for CAA record sets to
> be processed uniformly regardless of the CA, we would like to see these
> ambiguities resolved.
>
>
>
> If others agree that the current wording of the RFC is ambiguous, I would
> be happy to present changes to relevant sections to clear up the ambiguity,
> but for now I wanted to send this along to see if others share our
> interpretation of the RFC.
>
>
>
It's not clear to me that "relevant" is not defined by the RFC, given the
following:
  "Given a request for a specific domain X, or a request for a wildcard
   domain *.X, the relevant record set R(X) is determined as follows:"
combined with
  "Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X,"

The natural consequence of this is a hierarchy such that
subdomain1.subdomain2.example.com. IN CAA 0 iodef "mailto:
subdomainadmin@example.com"
subdomain2.example.com.                             IN    CAA 0 issuewild
";"
example.com.                                                  IN    CAA 0
issue "ca.example.com"

Means that subdomain1.subdomain2.example.com. is unrestricted by issuance
(i.e. the parent's restrictions do not apply) because the relevant record
set does not contain an issue field.

Similarly, subdomain2.example.com is prohibited from wildcards, but
otherwise, any CA can issue (e.g. example.com's restrictions do not apply)

However, example.com, and all subdomains *other than*
subdomain1.subdomain2.example.com, subdomain2.example.com, and *.
subdomain2.example.com are otherwise restricted