New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAA Lookup Loop Test #3

Open
ysf opened this Issue Sep 7, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@ysf

ysf commented Sep 7, 2017

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 added a commit that referenced this issue Sep 7, 2017

Remove cname-loop.basic.caatestsuite.com
Technically, if a CA can detect that there is a true loop,
then it is allowed to issue.  See #3.

This will be replaced by a better test.
@AGWA

This comment has been minimized.

Show comment
Hide comment
@AGWA

AGWA Sep 7, 2017

Member

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!

Member

AGWA commented Sep 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ysf

ysf Sep 7, 2017

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!

ysf commented Sep 7, 2017

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment