Re: [lamps] CAA for IP Address Certificates

[Antonios Chariton <[e-mail]>]

I have uploaded the document to the Datatracker here: https://datatracker.ietf.org/doc/draft-chariton-ipcaa/

> On 30 Nov 2022, at 20:14, Antonios Chariton <[e-mail]> wrote:
> 
> Hello everyone,
> 
> I was preparing this I-D for a few months now, and it’s interesting that the publication of that coincides with the S/MIME CAA record I-D[1]. Perhaps we can exchange ideas! :)
> 
> X.509 Certificates may include IP Addresses inside, e.g. in the Subject Alternative Names, the same way they can include domains. CAA records are only defined for domain names however, and there’s need to add support for IP addresses as well.
> 
> For this reason, I drafted https://daknob.github.io/draft-chariton-ipcaa/ (available in TXT: https://daknob.github.io/draft-chariton-ipcaa/draft.txt). I will upload it to Datatracker and share a link here soon.
> 
> The main idea is that CAA records are added in the “reverse DNS” zones, ip6.arpa and in-addr.arpa. Moreover, a new property is created to signal this type of CAA record.
> 
> I have circulated this to a few people to get some early feedback, so I am including here some design decisions, explanations, and answers to questions:
> 
> The Draft specifies the “ip” property. A common question was “why not issueip”? I felt like namespacing the property values depending on the particular need. For this reason, as “issue*” was used for TLS domain certificates and their subtypes (wildcard), I felt like the “ip*” namespace can be used for TLS IP certificates. I just saw that Corey chose “issuemail” for his Draft, but perhaps “mail*” would be a better namespace for that with this logic. We can always make it “ipissue” and “mailissue” if that’s better. What do you think of that? Future needs may arise for additional types that are better not left to parameters in the value.
> 
> Another question was why “issue” on these two DNS zones is not enough. The reason here is that I wanted to separate the two usecases, and not allow them to be mixed. Moreover, certificates for the domain name “0.16.5.193.in-addr.arpa” are valid, and we need to be able to tell whether the requestor limits issuance for this domain, or for the IP address 193.5.16.0. Note that CAA can apply to non-WebPKI CAs that are not bound by the CA/B Forum or Root Program requirements.
> 
> I didn’t want to have to create new parameters, e.g. “@ IN CAA 0 issue “example.com <http://example.com/>; onlyIP=1” and since Corey published the S/MIME draft I think it makes more sense now why this would not easily scale or why it’s not as clean of a solution.
> 
> To illustrate the support for multiple such usecases, in https://daknob.github.io/draft-chariton-ipcaa/#section-4-9 I added an example that includes both “issue” and “ip” properties where I explain the expected outcome. If you believe that this is not clear enough, I can rephrase it, or add additional text.
> 
> In the Deployment Considerations I mention that for IPv6, if there’s no CAA record, the CA may need to perform 32 DNS queries. I received some comments on whether this record can only exist at the full-address level (all 16 or 4 bytes), however I believe that this renders the hierarchical nature of DNS less useful, and e.g. an ISP with an IPv6 /29 allocation would need a zone file of 10^31 bytes. Other suggestions included picking an arbitrary number, e.g. 64 bits, however this still has the same concerns. Moreover, a lot of networks that deploy IPv6 today did not follow best practices and may assign e.g. all their VPS users’ address from within the same /64 network, in blocks of e.g. /112.
> 
> Assuming an average of ~3 DNS delegations in an ip6.arpa zone (IANA -> RIR, RIR -> LIR, Another one just in case), this would mean that up to 3 DNS servers may have to be queried in total, not 32. As some of these delegations and zones in general have high TTL values, I don’t personally expect a great rise in the number of DNS queries. Combined with the (currently) low issuance of IP Address certificates, I wouldn’t expect this to be a problem for either CAs or authoritative DNS servers. 
> 
> Much like NS records, an allocation that is not on the 4-bit boundary for IPv6 and on the 8-bit boundary for IPv4 may need more than one CAA record to cover a subnet. For example, an IPv4 /21 will require 8 CAA records minimum to cover it.
> 
> There may be “optimizations” for resolvers depending on their use and implementation of QNAME Minimization (RFC7816) [2].
> 
> Having a quick look at Corey’s draft, I think that this draft is clear enough, and I did not miss any additional Security Considerations :)
> 
> I am planning to solicit feedback from the Mozilla Dev Security Policy mailing list [3] as well, to determine whether there exist any concerns for this for use in the WebPKI.
> 
> Happy to receive any questions, suggestions, comments, etc. and discuss them here or privately.
> 
> Thanks,
> Antonis
> 
> 
> Sources
> 
> 1: https://mailarchive.ietf.org/arch/msg/spasm/chcrIZEit6HcdGyFGNzyiL7Dg6k/#
> 2: https://www.rfc-editor.org/rfc/rfc7816
> 3: https://groups.google.com/a/mozilla.org/g/dev-security-policy