CAA encoding

[birgelee]

https://github.com/bwesterb/draft-mpic/blob/67f9369432bb332c4ae8cc96da1912a212ca222f/draft-westerbaan-secdispatch-mpic.md?plain=1#L141

I noticed CloudFlare uses base64 representation of CAA records in their internal testing. Is there reason this is preferable to the Canonical Presentation Format for CAA expressed RFC 6844 Sec 5.1.1. which is more human readable?

[bwesterb]

From that same RFC:

Value: A sequence of octets representing the property value.
Property values are encoded as binary values and MAY employ sub-
formats.

So we might see a future new tag, that has a different preferred human readable format than value as character-string (defined in 5.1.1).

Also, parsing a character-string is a bit more of a hassle and easy to get wrong:

• How to interpret CAA 0 issue @?
• Will the client CAA 0 issue (lets\nencrypt) correctly?
• What is the meaning of a semicolon? CAA 0 issue letsencrypt.com;isthisacomment ; or this?
• This is allowed: CAA 0 issue \l\e\t\s\e\n\c\r\121pt.com

[TheEnbyperor]

I agree Base64 is probably better here to avoid DNS text parsing pitfalls.

The draft needs to be more specific on what exactly goes into the field. Is it the whole RR (RFC 1035 § 3.2.1), whole RRsets (RFC 1035 § 4.1), just the RDATA encoding (RFC 6844 § 5.1), or something else?

Drawing on points from my comment in #6 I think the DNSSEC chain (or lack there of) should also be returned. This provides some non-reputability of the CAA records, as well as allowing a CA to see if some vantage points see DNSSEC signatures where others don't - possibly a sign of meddling.

[birgelee]

@TheEnbyperor I think the idea of returning the DNSSEC chain is interesting. Do recommend any production DNS software that can produce these chains and also perform validation of the chains offline?

There also may be an added complexity in the Open MPIC case given that we rely on AWS's default DNS resolver. I believe it is DNSSEC validating, but we only get the AD bit back, not the entire chain.

[TheEnbyperor]

I'm not aware of any DNS software daemon that will return the entire chain, but I'm quite familiar with the hickory DNS package for Rust that I'm pretty sure will let you collect all that information - although I haven't checked the docs thoroughly for that. https://github.com/hickory-dns/hickory-dns

[birgelee]

Thanks @TheEnbyperor . Even though the resolver collects the information, I do not think there is any current support for packaging the DNSSEC chain info in a format for later consumption. Hickory DNS is also not fully production ready yet with some things like NSEC3 validation not being implemented.

We also work with Josh Aas who manages Hickory development, this may be something he would be interested in.

While I am interested in DNSSEC chain proofs, I hesitate a bit to put it into the standard without there being a substantial deployment ecosystem around the generation and consumption of such proofs.

[SulemanAhmadd]

I agree on maintaining Base64 encoding to make parsing of the records easier. I believe we would want to return each applicable RR from the set in the records field (in the current design). Its currently implied but we can make it explicit.

Resolvers validate the DNSSEC chains themselves and there is no current mechanism to return a "proof" to the client. Returning entire chains can also exceed practical limits of UDP message sizes 64K and can be a source of major amplification attack problem. Lets discuss this suggestion under a separate issue: #16