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

Tim Hollebeek <tim.hollebeek@digicert.com> Mon, 15 January 2018 17:44 UTC

Return-Path: <tim.hollebeek@digicert.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 DBDDB12E038 for <spasm@ietfa.amsl.com>; Mon, 15 Jan 2018 09:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 GHjHKG0ziY_X for <spasm@ietfa.amsl.com>; Mon, 15 Jan 2018 09:44:23 -0800 (PST)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.204]) (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 6C1F3126C0F for <spasm@ietf.org>; Mon, 15 Jan 2018 09:44:23 -0800 (PST)
Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-12.bemta-8.messagelabs.com id 64/D2-01246-678EC5A5; Mon, 15 Jan 2018 17:44:22 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGvTPTdkCqw4BybHCbuGJAMFFRNNb 4gg8aH5XUZcCxLXQhMwUxGtcEA8SIhrpUBIyIAUEDETUqRmtEqVusqBXEBRBkcUGNCxrjzNzi Mg833z3/f8495+YOTbI7dQZayHEJooO3cdpQKjCh/kKs640pJb7rWWLiwMBpKrHkcZqRSC4v/ 04k+57mUSuIFI3VkerMWaexFLtfUpntX1BOfeeK7cj3HOWjUJpi3hPQOHhZ3bCMm4DPd89p8K YRgbvpBZWPQmgtEw+PG24SCkcyy6Dup1+rcASzATynBhGOm6Gm+ocW8ywIvOtQ4xQzGbq6rqu 5esYEgaYqncIsYwRf/1HVH8IshvNtFaoHMaPhq69aZZKJgpbOUpWBiYRXD25rMY+Cno5fGuw3 wdFP3mCcg9aabwjzWPCXFqiTAXOWgCslr3VYiIP6fW+DpmXgveXWYNNJBCdqiigsxMCe68VBz oD+B4UkZhvktT0PJt8j4dKNJMzRcMZ7gMCFWjWwp7WdwGOuh6KqofY2w72eDg2+OgO0NeehQj Td88+kHjmfZEoRdDcW6zzqlYVD0+FOCptSoPNuf5BjwF3TG+QZUHGsj/QgWubp0PiQ+z+scBI cGrymxTwRigpe6TDPhr4bA6gMDa9CUyVBzBbE2DlxqaLVbHHZeastNiE+Mc4uSBJvFmx8qhSX 5rTXIfn1DZO/C+jj3iVeNIYmuFH6wqemFHZEqnP9JgsvWdaKWTZB8qJomuZAn9wta+GiYBZyN lht8hMekoEO4yL13xRZL2XydslqxpIPLaKbD3bnkvTZ9h55vaqugTd9uSRLOZwOwRClv6ikMU qaJcvxp+jQr+FHYw0ReiS3yYZlCqLd6vpf70VRNOIi9CalSpjV4fpzdq/cFiG3ta18ldKWi/8 rGbaj/bXSh9XN1MX0otfXKhdUtkx+No0v28ouDr9iFJIrd8+aMiktJP9+wtylMeeznVvuzFz4 MD00I3oqm913+Eve/F0rK47vLdxVG9uxnDdt8rPp9v0n5mUstD/K6so98qSgaVzJmnn9pfeNt pFcdcOMBqMYmLZlR5V//EhnUotm46WK9GqOkix8QgwpSvxvM1jisxUEAAA=
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-9.tower-220.messagelabs.com!1516038259!216267275!1
X-Originating-IP: [216.32.181.184]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20136 invoked from network); 15 Jan 2018 17:44:20 -0000
Received: from mail-by2nam01lp0184.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.184) by server-9.tower-220.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Jan 2018 17:44:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JG0o1Ts0nMQrH7bLM+4yw/qZt9qL78/wSjWJTZoVxCs=; b=FDNOMjy/wDkQe0bUF2xB4s/AfWv7J768UNXBLIAMnPuc6GGnwFBkSbVl3zB17bLwO27vfDRZ7GEcEDJU/ImFr3EINhSbuWNeaInozn2X07Jvuva5kPzsi8E7yTUUAgHMBglhOYSzAtoIDmkojEfvQFnG5nH6m1IKSx0JJLXDDek=
Received: from BN6PR14MB1283.namprd14.prod.outlook.com (10.173.162.145) by BN6PR14MB1282.namprd14.prod.outlook.com (10.173.162.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Mon, 15 Jan 2018 17:44:18 +0000
Received: from BN6PR14MB1283.namprd14.prod.outlook.com ([10.173.162.145]) by BN6PR14MB1283.namprd14.prod.outlook.com ([10.173.162.145]) with mapi id 15.20.0407.009; Mon, 15 Jan 2018 17:44:18 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Corey Bonnell <CBonnell@trustwave.com>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags
Thread-Index: AQHTi+4QDmko90Ob9kiZJwieEDaNDqN1K4rA
Date: Mon, 15 Jan 2018 17:44:18 +0000
Message-ID: <BN6PR14MB12834D559753106A52E556F283EB0@BN6PR14MB1283.namprd14.prod.outlook.com>
References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
In-Reply-To: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [74.111.107.128]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR14MB1282; 7:WxjAgjN9eUZZwSyPC5TTlxvqvHNuxcjGvjCPvO0CVHtuw0EMsOjjuap6HJEuTEwlrMY9ijYOcbo79tYwV4ezGVWQc+2Wd8LRwB87OtqUPpZpEDZFpVOzEZqIyaA22w1N+QV1vpnI7HkdsKK/RL/6MsGBSt07v3TILXuV+RToN0jPEYDApHTdih8+SHQ3KDgYSUMBErUYqMVzo+gWWnlBWv0hmHc4BAA0CZwhJtt05q2ZtrvQI67golQJhNMW51jx
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3a7908c0-fae0-47cf-c813-08d55c3f9a72
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1282;
x-ms-traffictypediagnostic: BN6PR14MB1282:
x-microsoft-antispam-prvs: <BN6PR14MB1282A5DA8215D231375B742383EB0@BN6PR14MB1282.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(171964332516350)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231023)(944501161)(10201501046)(6041268)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:BN6PR14MB1282; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR14MB1282;
x-forefront-prvs: 0553CBB77A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(39380400002)(376002)(396003)(366004)(346002)(189003)(199004)(316002)(66066001)(14454004)(99286004)(76176011)(7696005)(106356001)(478600001)(97736004)(606006)(2501003)(6436002)(53546011)(2906002)(102836004)(59450400001)(3846002)(2900100001)(6116002)(790700001)(110136005)(6506007)(86362001)(6246003)(53936002)(9686003)(54896002)(236005)(6306002)(25786009)(3280700002)(33656002)(3660700001)(2950100002)(105586002)(229853002)(8676002)(81166006)(74316002)(8936002)(81156014)(7736002)(5660300001)(55016002)(68736007)(77096006)(99936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1282; H:BN6PR14MB1283.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: npmqlE54Qii/rat58PhSrn9f8/jwSe54SLYJA2z89JgCqADSdlRdZludAOsjp1ESxHyj3g0DnG92SLaJMmwotg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0177_01D38DED.C2BB59A0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a7908c0-fae0-47cf-c813-08d55c3f9a72
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2018 17:44:18.4983 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1282
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/IRfvK-V4EoFyb6tiMbV634PNxdU>
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: Mon, 15 Jan 2018 17:44:28 -0000

So the problem at hand is the difference between CAA records that don’t exist (case A), and CAA records that exist but have no “issue” records (case B).  I’ll discuss the following subcases:

 

Case B1: ihatewildcards.example.com    CAA 0 issuewild “;”

 

Case B2: ineedcoffee.example.com          CAA 0 isue “digicert.com”

 

Your interpretation of Section 3 cannot be the intent of the RFC because it would render language elsewhere unnecessary (specifically, language like “the issue property tag is used to request that certificate issuers perform CAA issue restriction” that you noted).  I think the root of the ambiguity is the first paragraph of Section 4 where it says “consistent with the applicable CAA Resource Record set”.  I think it’s clear that despite having no definitions, “applicable Resource Record set” and “relevant record set” both refer to the results of the search algorithm specified in Section 4.  

 

In case A, that set is empty (see the last bullet point), in which case the “If such a record set exist, …” in the previous sentence makes the interpretation clear.  Issuance is allowed.

 

In case B, the set is not empty, so we’re left with what “consistent with” means.  And that’s subject to interpretation.  However as noted above, I think the intent is clear.  The RFC even goes out of its way to describe an alternative syntax for “Do not issue” (namely, ‘issue “;”’), so there is no need for lack of an issue tag to mean do not issue, as it would become semantically redundant with issue “;”.

 

The “no issue tag means no restrictions” interpretation allows you to express the “no restrictions” policy, which cannot be expressed in any other way without listing every CA out there, including ones that don’t exist yet.

 

The “no issue tag means no issuance” case breaks the important use case B1, which specifies that normal certificates are fine but wildcards are not.

 

The only case that can be made in favor of the “no issue tag” meaning no issuance is case B2, but the correct way of fixing that is to mark tags that you don’t want to be ignored as critical.  If you mark your issue tags critical, they will fail closed as desired.

 

So, in summary, I think the intent of the RFC is clear, and there is a perfectly reasonable interpretation of “consistent with” that is … uh … consistent with that intent 😊, and that “CAA restriction processing” (used twice) must be requested by including an “issue” tag (or “issuewild” [1]) before any request can be inconsistent with the returned record set.

 

As always, CAs are free to be more restrictive with issuance than required, but in this case I think the looser interpretation is better since it agrees with the intent and allows important use cases like B1.  It also will be important for the upcoming CAA tags as you will need to be able to express “I’m fine with any CA, as long as they don’t use method 5.”

 

I’ll add it to the Validation WG agenda for this week so we can see what other CAs think.

 

-Tim

 

[1] The description of “issuewild” states that it has the same semantics as “issue”, so it also requests CAA issue restriction processing.

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Corey Bonnell
Sent: Friday, January 12, 2018 2:41 PM
To: spasm@ietf.org
Subject: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

 

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.

 

Thanks,

Corey

 

 

 

Corey Bonnell

Senior Software Engineer

t: +1 412.395.2233

 

Trustwave | SMART SECURITY ON DEMAND <http://www.trustwave.com/> 
www.trustwave.com

 

2017 Best Managed Security Service Winner – SC Media