search

SSLMate / caatestsuite

Test suite which checks compliance with CAA checking as defined in version 1.4.8 of the CABF Baseline Requirements
https://caatestsuite.com
Apache License 2.0
10 stars 4 forks source link

CAA Lookup Loop Test #3

Open ysf opened 6 years ago

ysf commented 6 years ago

I don't understand yet why this test should fail implicitly. The CA should not run into the recursion loop, yes. But can't basic.caatestuite.com, caatestsuite.com and .com be checked for CAA records after the recursion has been detected? Since no CAA records are defined for any of those domains, issueing could be allowed, couldn't it? Thanks for any pointers and your suite in general!

AGWA commented 6 years ago

You raise a good point. If the CA can detect that there is a true loop, then it knows there is no CAA record set at that label and can continue upwards, and ultimately issue.

What the CA must not do is assume that just because there is a long chain of CNAMEs that there must be a loop. This is what the cname-loop test was trying to check. I've removed this test for now and will replace it with a better test.

Thanks for filing this issue!

ysf commented 6 years ago

Detection of a true loop is easily implemented and should not be blocker for any CA. I had some true loops which were simple misconfigurations of peoples DNS or domain/subdomain plan. They exist more often than I thought.

An attacker could write/modify a DNS that returns dynamicly created C/DNAME records pointing to other dynamicly created C/DNAMES which point to ... , and so on, creating an endless lookup-chain without any recursion ever happening. This could result in a potential DoS of the CAA Lookup service if not handled via timeout.

I think this is something erratum 5065 tries to solve. Limiting the length of CNAME chains, however, is only a solution if it'll result in a deny, which is not yet defined. We'll see. :)

Thanks again for your work!