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

Quirin Scheitle <scheitle@net.in.tum.de> Mon, 15 January 2018 14:52 UTC

Return-Path: <scheitle@net.in.tum.de>
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 426B412D7F3 for <spasm@ietfa.amsl.com>; Mon, 15 Jan 2018 06:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 YIwiCpc3rNQO for <spasm@ietfa.amsl.com>; Mon, 15 Jan 2018 06:52:07 -0800 (PST)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B691200C1 for <spasm@ietf.org>; Mon, 15 Jan 2018 06:52:07 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 5; Mon, 15 Jan 2018 15:51:57 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Quirin Scheitle <scheitle@net.in.tum.de>
In-Reply-To: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
Date: Mon, 15 Jan 2018 15:51:57 +0100
Cc: "spasm@ietf.org" <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <10AA872D-C62C-4152-AF90-8E1A838BD2AF@net.in.tum.de>
References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com>
To: Corey Bonnell <CBonnell@trustwave.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/_jwi-J8b_581mgGRbckvRTyZMCo>
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 14:52:09 -0000

Hi Corey,

> On 12. Jan 2018, at 22:41, Corey Bonnell <CBonnell@trustwave.com> wrote:
> 
> - 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.
> 

I agree that these are ambiguous and it would be beneficial to clarify. 
My interpretation so far has been #3, based on the following interpretations/assumptions: 
	1) Lack of issue tag means "no restrictions” (except issuewild/wildcard specifics, following Sec 5.2)
	2) presence of a CAA record (with any content) stops tree climbing
	3) any unknown non-critical (such as “iisue”) tags are ignored


There seem to be some, but not many cases affected:
As of this morning, we scanned 122,207 base domains with CAA records, of which 122,076 had an issue or issuewild tag. Of these, 1707 have an issuewild but not an issue tag [how would you handle a non-wildcard CSR for these in your current logic?]. 
I can dig up some more/different numbers if helpful, but I believe this already shows that there is a non-trivial amount and further clarification might be helpful. 
This could also be fixable in a CA/B ballot. 

Kind regards
Quirin