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

Tim Hollebeek <tim.hollebeek@digicert.com> Tue, 27 March 2018 01:37 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 155BD128D2E for <spasm@ietfa.amsl.com>; Mon, 26 Mar 2018 18:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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, T_KAM_HTML_FONT_INVALID=0.01, 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 jdZHANLrf5Uh for <spasm@ietfa.amsl.com>; Mon, 26 Mar 2018 18:37:50 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (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 ABEAE126DC2 for <spasm@ietf.org>; Mon, 26 Mar 2018 18:37:50 -0700 (PDT)
Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-17.bemta-8.messagelabs.com id E9/1B-05522-C60A9BA5; Tue, 27 Mar 2018 01:37:48 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0gUURTHuzPj7vjYuK6v06I9tjLc0Aystvp QEYHRuw9BJtiok7u0L3ZWsyIqKcG2VEJJpVqjTVLUQiQUzNa1krQgdSs1xTRDUzFXDanoMbMz vebD5XfP/3/OPfdwhyaVV+Qqms22sVYTY1DLAqiepfXrY4+XNybFO6+s13q9tZS21PNFpr35O m0rmTg1M+qX6HR+IRLbe/Oo/WSSn96Uas4+6qdr6vbILYXNKPui/cQ5VFmLLqEAmsKfCOgbdM uEjRIXE1A5NC4XN+8QXM6xk5eQPy3D8fD6YRshcCi2wZjrOSVwCDZB2+dHMjFuhuuv3ki8Cao LOn25FF4Jk3e8vlwFToaBn+d9rMQWuOMq59ugaX+8GXrno4UwwuEw317ts5A4AvpGHD4GHApD nR0ykcPg4/sffqI/GW7MuqW4Gmon+yV/FHQ57L5bAq4nIP+xUy4KsTBdXEyKvAfmf7RLpi4EF a4pSdDA1MiAlHAcSitbpapnIH+ukRQTnCQ86SiQjo6E76N1hChclcFkU4N0zXQoqhIHDPgbAR UXLpDi7FQw4MlDhSim7J+7lvE+EjsQ1M/1U2W+mQXDs9IRSjQlgauplRBZA8U141J8NVTcmiD L+FmSOAaedqv/Dwu8GUq+tshEXgZF9iG5yOtg4okXlaPAKrSKY61ZrDU2IS7Vqs/Q2YyM3hC7 Nl4bZ2Q5jslgDUwqF5dmNtYh/iEu4L8G1J+/3Y0W0YQ6THFqSWOScmGqOf2kjuF0KdZMA8u5U SRNq0HBOHgt2MpmsNnH9Ab+Nf+WgQ5ShyosN3lZwVkYI6fPEKV2tIX2XBvNJen64Y/86vKtPW MTuaSSMplNrCpCsVSoioU0XabpT9Hff0kXilKFKBDfpjLIwlqNetv/+jiKoJE6RLFOqBKkN9n +nD3Ot0XwbT3IaRDasjF/JdU5RM7mnWZa092uzqdR+/rG7v7c7byHb+d4Ck7WJHQmbjNqCxc0 OJZMH578HuPdkwwzytxrM3OqjYtVltIjOQdGltUGhkeXG19UlWwtij77wb/CoMnqKfEefJuyd 7vGnblmheflhprzuuHIRS27dw4e2vVph3JLgXe2+b6d6t20a3lmoJridMxaDWnlmF8kkAOIIA QAAA==
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-13.tower-94.messagelabs.com!1522114666!186154790!1
X-Originating-IP: [216.32.180.54]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 86908 invoked from network); 27 Mar 2018 01:37:47 -0000
Received: from mail-by2nam03lp0054.outbound.protection.outlook.com (HELO NAM03-BY2-obe.outbound.protection.outlook.com) (216.32.180.54) by server-13.tower-94.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 27 Mar 2018 01:37:47 -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=6Xx5OviW+NjfcNFX6pf/23KcNIiyn5dNH8/YaP4CGP8=; b=mGg8TcD84pQtmsyZxR4Ah+eT8lCPDupOdxNEG/f7FM3XhglMCtXrLM3M9fiY+pMncjE3QmPpSWHVKYEKa309PVl/gnYrm2qtqf4VNC+GNPLdG3V0lg8agzJZCt/lBsT0MMCBb4FEyShrDf+72fNdkgQsYYKKwYWzGoR6s2dBIzo=
Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1261.namprd14.prod.outlook.com (10.173.102.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Tue, 27 Mar 2018 01:37:45 +0000
Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd%17]) with mapi id 15.20.0609.012; Tue, 27 Mar 2018 01:37:46 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Jacob Hoffman-Andrews <jsha@eff.org>, Corey Bonnell <CBonnell@trustwave.com>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags
Thread-Index: AQHTi+4QDmko90Ob9kiZJwieEDaNDqPjolkAgAAeGoA=
Date: Tue, 27 Mar 2018 01:37:46 +0000
Message-ID: <MWHPR14MB1376936E9A08BCA8D4F83A8883AC0@MWHPR14MB1376.namprd14.prod.outlook.com>
References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> <ed4efa8d-c82f-018e-143c-63388e540763@eff.org>
In-Reply-To: <ed4efa8d-c82f-018e-143c-63388e540763@eff.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [98.111.253.132]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR14MB1261; 7:4EYVRtYCEvD5BVQNKy+dwU4FzZCXnyuhEALQe1rK80yzNLwCJxDIafoyFwH/SGEVxt+hNd4gbNVc3mkXwameN2/+q3MPQNemnL/h0qklAKZuKGFbxxhwzD81jbD4GE6xoh+QB0vD/igCfc5rS0aiCpc5wRg7VX6sAGdiDSAQRCpkmTJaJ0BuIWxk+vpScLSX60w8Neo9i2HfeEpHxsPxwISTApVzhlTtENbFD0Rz4Epc3o/UDNnMqXlmnIMTAv1b
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 99ee89eb-959e-42d4-c65f-08d593835785
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1261;
x-ms-traffictypediagnostic: MWHPR14MB1261:
x-microsoft-antispam-prvs: <MWHPR14MB1261E8AF447C461B8F4496DE83AC0@MWHPR14MB1261.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(192374486261705)(171964332516350)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR14MB1261; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1261;
x-forefront-prvs: 0624A2429E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39860400002)(396003)(346002)(376002)(199004)(189003)(53936002)(6246003)(8936002)(5250100002)(3280700002)(2501003)(66066001)(68736007)(33656002)(11346002)(446003)(99286004)(81156014)(81166006)(7736002)(478600001)(606006)(966005)(486005)(486005)(316002)(8676002)(2906002)(229853002)(6436002)(26005)(186003)(110136005)(7696005)(97736004)(59450400001)(5660300001)(3660700001)(105586002)(106356001)(6306002)(54896002)(2900100001)(25786009)(14454004)(3846002)(99936001)(76176011)(86362001)(6506007)(790700001)(53546011)(55016002)(74316002)(102836004)(476003)(236005)(6116002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1261; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RqoJ53iS6uTvIdSdNdjWeFYW+thSfAUVIO0Z07FVu/ur9PSeAL1tNL2/fiWYOfycVsefRnwrt0VgwtLVgxBoj7/cRa/lpvIQ/2E2662E3KIvoodbD2uPtfgct1u7O/Iu9PZSthoGknKlZS5X3gd50LkHRIGt7Mg09CGPjNaY/WKhjKg7v3yT2Lxo/++jvsrffrgq6QJVxwEMJyzLOvleg7ho1DP9yuPQPb7SWxRSiMndU9rUAbSYQ3er75mYVZKNyrqw66+j/qiOmcv8uq1ApnUSrHDDnSNgsj+htObSATKfdRKS0CRexDSGTqEXRfe91W0i+jeTtlDF+Hz/s4dN6g==
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_0101_01D3C54A.ACD75000"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 99ee89eb-959e-42d4-c65f-08d593835785
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 01:37:46.0239 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1261
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/kzHDPQJkHzpNehuahXOWIM91lT8>
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: Tue, 27 Mar 2018 01:37:54 -0000

Looks good to me.

 

Thanks Jacob.

 

-Tim

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jacob Hoffman-Andrews
Sent: Monday, March 26, 2018 7:50 PM
To: Corey Bonnell <CBonnell@trustwave.com>om>; spasm@ietf.org
Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

 

I've written this up as a PR: https://github.com/jsha/caa-simplification/pull/1/files. If there are no objections, I'll merge it in a week for the 6844bis draft.

Note that I tweaked it slightly from your erratum (https://www.rfc-editor.org/errata/eid5244). Where you referred just to "issue" property tags, I mention both "issue" and "issuewild."

On 01/12/2018 01:41 PM, Corey Bonnell 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.

 

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






_______________________________________________
Spasm mailing list
Spasm@ietf.org <mailto:Spasm@ietf.org> 
https://www.ietf.org/mailman/listinfo/spasm