On 14/09/2017 01:13, Matthew Hardeman wrote:
On Tuesday, September 12, 2017 at 5:36:56 AM UTC-5, Gervase Markham wrote:
As the drafter of the section :-), my intent was to make it so that if a
site owner were concerned about the possibility that their CAA record or
DNS could be spoofed, they could use DNSSEC to solve the problem. I
agree that there is an implicit assumption in this requirement, that it
is possible to efficiently determine the presence or absence of what we
might call "attempted DNSSEC" for a particular domain. (That's not the
same thing as "correct, valid, properly-signed, whatever DNSSEC.) If
that assumption is not true, we may have to reconsider.
The proper mechanism is, of course, proper DNSSEC validation of each step of
each of the CAA queries.
The only "light" mechanism I can imagine is likely to shave only a little time
off of common cases and is more likely to introduce bugs and errors for edge cases than
it will help, but here goes:
I _think_ the only "light" DNSSEC validation shortcut that might pass muster
would be:
1. Chase validation to TLD from root zone.
2. Query for DS record delegation for second-level-domain from the TLD
servers, validating proper signature on the DS results or proper signature on
the proof-of-non-existence of the DS records for the SLD.
3. If the SLD has DS records at the registry and these DS results are signed
by the registry, assume that the SLD and all downline subordinates of the SLD
have DNSSEC configured and perform full DNSSEC validation on each CAA query.
If the SLD has no DS records in the TLD registry and this has been _proven_ by
a validly signed proof-of-nonexistence by the TLD registry servers, then DNSSEC
for the SLD and subordinate zones is moot and could be ignored.
For the common case, I don't think that will shave off much time.
Additionally, in terms of complexity, if you implement the above correctly,
you've written the vast majority of the code necessary to finish it out the
rest of the way.
Ultimately, a decision must be made as to whether or not the CA is responsible
to ensure that the CAA records (or in the alternative that the non-existence of
the CAA records) are fully DNSSEC validated wherever there is not a
cryptographic proof that the zone doesn't support DNSSEC (Exempting for TLDs
not supporting DNSSEC).
Matt Hardeman
Wouldn't the following also work:
1. Use a (non-broken) DNSSEC-validating recursive resolver/dnscache
server running in the CA's own network. Use more than one for
redundancy. This server will do all the DNSSEC checking and chasing.
The network connection to this server must be secure.
2. If a DNS query response is NOERROR or NXDOMAIN and has the AD bit
set, it is known to be validly signed.
3. If a DNS query response is NOERROR or NXDOMAIN, and does not have AD
set, then it is a valid response from a zone that does not have a
DNSSEC chain to the root zone.
4. If a DNS query response times out or is SERVFAIL, wait a bit then try
again (a limited number of times).
5. If a DNS query response is ultimately anything else, something
is wrong at the customer end (their DNS is broken), at the CA end (the
DNS resolver/cache failed), or an attack is in progress. Neither
should result in issuance.
Note that the above is not specific to CAA, it should also work for any
A, AAAA, TXT or other records looked up during domain checks.
Note that a missing record (such as a missing CAA record) would result
in a valid response that is NOERROR or NXDOMAIN and which indicates that
no such record is there.
Real world experience may add a few other error codes indicating valid
absence of a record in an unsigned zone.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
