CAA Certificate Problem Report

[Jeremy Rowley]

Hi everyone,



We received a certificate problem report at 11 pm on Sep 8, 2017 from Andrew
Ayer alleging the mis-issuance of 6 certificates because of a failure to
properly verify CAA records.



I'm sharing the report here because there are questions about CAA record
checking that we feel are better shared with the broader community. We're
looking for clarification on whether these are a) mis-issuances based on a
misunderstanding of the requirement, b) an issue with the test suite used to
verify CAA compliance, or c) gaps in the RFC/BRs. The report:



[DigiCert] issued the following certificates in violation of the Baseline
Requirements' CAA checking requirement:



1.
https://crt.sh/?sha256=26F4FFABCF94AA16A85C7F02D9F4604E74A41ACE51DA1C55B732E
1618798D04A

2.
https://crt.sh/?sha256=2619EAA800BA627CC3C1971DF0BB8006B2831B500935E94379952
4E81CA3EDAB

3.
https://crt.sh/?sha256=D0DA8826B05D5A079E4356D4FED6300A94B0E2B9E6E40FCB6AAEA
C1F2163AF2E

4.
https://crt.sh/?sha256=300D20D0E63112AD77D09BBA8F02E9B075E265DF21E0FE6F18C38
CD11179D43B

5.
https://crt.sh/?sha256=CC08B270A8BF66D431E9AC073C7014373F6CE582F1CF5C08CF73C
340F91327FB

6.
https://crt.sh/?sha256=A3AA9FDC0ED72C29C969E76A929F517EB093A574ED2C248CBAFC7
85767403FC6



Certificate 1 contains a single DNS identifier for
big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> . This DNS
name has a CAA resource record set that is too large to fit within a single
DNS UDP packet, but small enough to fit within a DNS TCP packet. The only
CAA record containing an issue property is:

big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> . IN
CAA 0 issue "caatestsuite.com <http://caatestsuite.com> "

Therefore, only caatestsuite.com <http://caatestsuite.com> is allowed to
issue for this identifier.



[JR] We only check CAA records with UDP to keep performance good on certs
with hundreds of SANs. I couldn't find a requirement that mandates use of
TCP to check CAA records. Should TCP be required?



Certificate 2 contains a single DNS identifier for
cname-deny-sub.basic.caatestsuite.com
<http://cname-deny-sub.basic.caatestsuite.com> . The following DNS records
are

relevant:

cname-deny-sub.basic.caatestsuite.com
<http://cname-deny-sub.basic.caatestsuite.com> . IN CNAME
sub.deny.basic.caatestsuite.com <http://sub.deny.basic.caatestsuite.com> .

deny.basic.caatestsuite.com <http://deny.basic.caatestsuite.com> . IN CAA 0
issue "caatestsuite.com <http://caatestsuite.com> "

There is no CAA record at sub.deny.basic.caatestsuite.com
<http://sub.deny.basic.caatestsuite.com> . According to RFC 6844, the only
CA allowed to issue for cname-deny-sub.basic.caatestsuite.com
<http://cname-deny-sub.basic.caatestsuite.com>

is caatestsuite.com <http://caatestsuite.com> .



[DC] I don't read the RFC this way. I know both the CAB Forum and IETF hotly
debated CNAME's interplay with CAA a couple of times, but I thought we were
awaiting on adoption of the Errata to determine the proper resolution. My
interpretation of the RFC remains that the CA verifies X.Y.Z, then the
alias of X.Y.Z, then Y.Z, then alias of Y.Z, etc. If A.B.C. is the alias
of X.Y.Z, you'd only verify the CAA record at A.B.C., not A.B.C. followed by
B.C. followed by C. This is perhaps clarified in the RFC errata, but that
is not official yet and not part of the BR requirement. I don't think
there's sufficient clarity around the correct CAA-CNAME process to implement
a code change.



Certificate 3 contains a single DNS identifier for
refused.caatestsuite-dnssec.com <http://refused.caatestsuite-dnssec.com> .
Attempts to query the CAA record for this DNS name result in a REFUSED DNS
response. Since there is a DNSSEC validation chain from this zone to the
ICANN root, CAs are not permitted to treat the lookup failure as permission
to issue.



[DC] This will always issue. A refusal is treated as a failure. Under the
BRs a failure is permission to issue if we retry and DNSSec is not present.
However, although DNSSec is present on the test suite's side, we can't see
it. Therefore, we get refused (a lookup failure), retry (resulting in
another lookup failure), followed by a DNSSec check (which fails because
retrieving the RSSIG record is refused). There's no path under which this
won't issue because we can't see whether DNSSec is present.



Certificate 4 contains a single DNS identifier for
missing.caatestsuite-dnssec.com <http://missing.caatestsuite-dnssec.com> .
This DNS name has no CAA records, but the zone is missing RRSIG records.
Since there is a DNSSEC validation chain from this zone to the ICANN root,
the DNS lookup should fail and this failure cannot be treated by the CA as
permission to issue.



[DC] I believe this is properly issued. We retrieved the DNS record (no
failure) and found no CAA record present. The relevant portion of the BRs
state: "CAs are permitted to treat a record lookup failure as permission to
issue if: . the failure is outside the CA's infrastructure; . the lookup has
been retried at least once; and . the domain's zone does not have a DNSSEC
validation chain to the ICANN root." Although there is a valid DNSSEC chain
to the root, issuance is still permitted because there was no lookup
failure.



Certificate 5 contains a single DNS identifier for
expired.caatestsuite-dnssec.com <http://expired.caatestsuite-dnssec.com> .
This DNS name has no CAA records, but the zone contains expired RRSIG
records. Since there is a DNSSEC validation chain from this zone to the
ICANN root, the DNS lookup should fail and this failure cannot be treated by
the CA as permission to issue.



[DC] As with 4, I believe this is properly issued. We retrieved the DNS
record (no failure). The DNS lacked a CAA record. Although there is a valid
DNSSEC chain to the root, issuance is still permitted because there was no
lookup failure.



Certificate 6 contains a single DNS identifier for
blackhole.caatestsuite-dnssec.com <http://blackhole.caatestsuite-dnssec.com>
. All DNS requests for this DNS name will be dropped, causing a lookup
failure. Since there is a DNSSEC validation chain from this zone to the
ICANN root, CAs are not permitted to treat the lookup failure as permission
to issue.



[DC] Retrieval of the RSSIG record is failing, which we interpreted as the
lack of DNSSec. If the DNSSec check times out, we issue because 1) The DNS
lookup failed, 2) we retried the DNS lookup and it failed again, and 3)
DNSSec is absent (because the RSSIG record lookup failed).



Thoughts?



Jeremy

[Peter Bowen]

> Certificate 3 contains a single DNS identifier for
> refused.caatestsuite-dnssec.com

> Attempts to query the CAA record for this DNS name result in a REFUSED DNS
> response. Since there is a DNSSEC validation chain from this zone to the
> ICANN root, CAs are not permitted to treat the lookup failure as permission
> to issue.
>
>

> Certificate 4 contains a single DNS identifier for
> missing.caatestsuite-dnssec.com <http://missing.caatestsuite-dnssec.com> .
> This DNS name has no CAA records, but the zone is missing RRSIG records.
> Since there is a DNSSEC validation chain from this zone to the ICANN root,
> the DNS lookup should fail and this failure cannot be treated by the CA as
> permission to issue.
>

> Certificate 6 contains a single DNS identifier for
> blackhole.caatestsuite-dnssec.com <http://blackhole.caatestsuite-dnssec.com>
> . All DNS requests for this DNS name will be dropped, causing a lookup
> failure. Since there is a DNSSEC validation chain from this zone to the
> ICANN root, CAs are not permitted to treat the lookup failure as permission
> to issue.

Based on my own queries, I do not believe the statement that there is
"a DNSSEC validation chain from this zone to the ICANN root" is
correct for these.

All of these names have NS records in the parent zone, indicating they
are zones themselves:

refused.caatestsuite-dnssec.com. 60 IN NS nsrefused.caatestsuite-dnssec.com.
blackhole.caatestsuite-dnssec.com. 60 IN NS nsblackhole.caatestsuite-dnssec.com.
missing.caatestsuite-dnssec.com. 60 IN NS ns0.caatestsuite-dnssec.com.
missing.caatestsuite-dnssec.com. 60 IN NS ns1.caatestsuite-dnssec.com.

In all three of these cases, the "domain's zone does not have a DNSSEC
validation chain to the ICANN root" -- I requested SOA, DNSKEY, NS,
and CAA records types for each zone and in no case did I get a
response that had a valid DNSSEC chain to the ICANN root.

This leads me to believe these tests are incorrect and I agree with
Jeremy's conclusion for these.

Thanks,
Peter

[Jonathan Rudenberg]

For reference, here is the relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398428

> On Sep 9, 2017, at 05:21, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> big.basic.caatestsuite.com

>
> [JR] We only check CAA records with UDP to keep performance good on certs
> with hundreds of SANs. I couldn't find a requirement that mandates use of
> TCP to check CAA records. Should TCP be required?

Not using TCP is fine. However, if the TC (truncation) bit is set (as it is in this case), you cannot know if you’ve received the complete CAA record set and must refuse to issue.

> refused.caatestsuite-dnssec.com

>
> [DC] This will always issue. A refusal is treated as a failure. Under the
> BRs a failure is permission to issue if we retry and DNSSec is not present.
> However, although DNSSec is present on the test suite's side, we can't see
> it. Therefore, we get refused (a lookup failure), retry (resulting in
> another lookup failure), followed by a DNSSec check (which fails because
> retrieving the RSSIG record is refused). There's no path under which this
> won't issue because we can't see whether DNSSec is present.

It sounds like your DNSSEC implementation is incorrect. To do the lookup properly, you’d walk down from the root zone doing DNSSEC validation and find that the lookup state is ‘Bogus’ due to the refused DNSKEY query.

Here’s a graphic that shows this: http://dnsviz.net/d/refused.caatestsuite-dnssec.com/dnssec/

> missing.caatestsuite-dnssec.com

>
> [DC] I believe this is properly issued. We retrieved the DNS record (no
> failure) and found no CAA record present. The relevant portion of the BRs
> state: "CAs are permitted to treat a record lookup failure as permission to
> issue if: . the failure is outside the CA's infrastructure; . the lookup has
> been retried at least once; and . the domain's zone does not have a DNSSEC
> validation chain to the ICANN root." Although there is a valid DNSSEC chain
> to the root, issuance is still permitted because there was no lookup
> failure.

The DNSSEC lookup state is Bogus here too, because there is no valid RRSIG record. There is a lookup failure when using a properly implemented client.

http://dnsviz.net/d/missing.caatestsuite-dnssec.com/dnssec/
https://dns.google.com/query?name=missing.caatestsuite-dnssec.com&type=CAA&dnssec=true


> expired.caatestsuite-dnssec.com

>
> [DC] As with 4, I believe this is properly issued. We retrieved the DNS

> record (no failure). The DNS lacked a CAA record. Although there is a valid

> DNSSEC chain to the root, issuance is still permitted because there was no
> lookup failure.

Again, the lookup state is Bogus, due to the expired RRSIG. This should result in a lookup failure.

http://dnsviz.net/d/expired.caatestsuite-dnssec.com/dnssec/
https://dns.google.com/query?name=expired.caatestsuite-dnssec.com&type=CAA&dnssec=true


> blackhole.caatestsuite-dnssec.com

>
> [DC] Retrieval of the RSSIG record is failing, which we interpreted as the
> lack of DNSSec. If the DNSSec check times out, we issue because 1) The DNS
> lookup failed, 2) we retried the DNS lookup and it failed again, and 3)
> DNSSec is absent (because the RSSIG record lookup failed).

The eTLD+1 has a DNSSEC validation chain to the ICANN root, so it is not absent.

http://dnsviz.net/d/blackhole.caatestsuite-dnssec.com/dnssec/

[Jonathan Rudenberg]

> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> In all three of these cases, the "domain's zone does not have a DNSSEC
> validation chain to the ICANN root" -- I requested SOA, DNSKEY, NS,
> and CAA records types for each zone and in no case did I get a

> response that had a valid DNSSEC chain to the ICANN root.

This comes down to what exactly “does not have a valid DNSSEC chain” means.

I had assumed that given the reference to DNSSEC in the BRs that the relevant DNSSEC RFCs were incorporated by reference via RFC 6844 and that DNSSEC validation is required. However, this is not entirely the case, using DNSSEC for CAA lookups is only RECOMMENDED in section 4.1 and explicitly “not required.” Which means this is all pretty pointless. The existence or non-existence of DNSSEC records doesn’t matter if there is no requirement to use them.

Given this context, I think that your interpretation of this clause is not problematic since there is no requirement anywhere to use DNSSEC.

I think this should probably be taken to the CAB Forum for a ballot to either:

1) purge this reference to DNSSEC from the BRs making it entirely optional instead of just having this pointless check; or
2) add a requirement to the BRs that DNSSEC validation be used from the ICANN root for CAA lookups and then tweak the relevant clause to only allow lookup failures if there is a valid non-existence proof of DNSSEC records in the chain that allows an insecure lookup.

None of my comments in this thread should be interpreted as support for DNSSEC :)

Jonathan

[Andrew Ayer]

On Sat, 9 Sep 2017 08:49:01 -0700

Peter Bowen via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg
> <jona...@titanous.com> wrote:
> >
> >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
> >> <dev-secur...@lists.mozilla.org> wrote:
> >>
> >> In all three of these cases, the "domain's zone does not have a
> >> DNSSEC validation chain to the ICANN root" -- I requested SOA,
> >> DNSKEY, NS, and CAA records types for each zone and in no case did
> >> I get a response that had a valid DNSSEC chain to the ICANN root.
> >

> > This comes down to what exactly ___does not have a valid DNSSEC
> > chain___ means.

> >
> > I had assumed that given the reference to DNSSEC in the BRs that
> > the relevant DNSSEC RFCs were incorporated by reference via RFC
> > 6844 and that DNSSEC validation is required. However, this is not
> > entirely the case, using DNSSEC for CAA lookups is only RECOMMENDED

> > in section 4.1 and explicitly ___not required.___ Which means this is

> > all pretty pointless. The existence or non-existence of DNSSEC

> > records doesn___t matter if there is no requirement to use them.

> >
> > Given this context, I think that your interpretation of this clause
> > is not problematic since there is no requirement anywhere to use
> > DNSSEC.
> >
> > I think this should probably be taken to the CAB Forum for a ballot
> > to either:
> >
> > 1) purge this reference to DNSSEC from the BRs making it entirely
> > optional instead of just having this pointless check; or
> > 2) add a requirement to the BRs that DNSSEC validation be used from
> > the ICANN root for CAA lookups and then tweak the relevant clause
> > to only allow lookup failures if there is a valid non-existence
> > proof of DNSSEC records in the chain that allows an insecure lookup.
> >
> > None of my comments in this thread should be interpreted as support
> > for DNSSEC :)
>

> My recollection from the discussion that led to the ballot was that
> this line in the BRs was specifically to create a special hard fail if
> the zone was properly signed but the server returned an error when
> looking up CAA records.

Your recollection is not consistent with the most recent cabfpub thread
on the topic: https://cabforum.org/pipermail/public/2017-August/011800.html

> As a big of background, in order to be properly signed [...]

The BRs do not say that the zone has to be "properly signed" for this
line to trigger. Nor do they require a "valid chain" of signatures
from particular records in the zone to the root, as you suggested in
another email.

Rather, the BRs say the line triggers if there is "a DNSSEC validation
chain to the ICANN root." A "validation chain" doesn't mean signatures,
but rather the information needed to validate the zone. "Validation
chain" is not the precise term that DNSSEC uses, but the synonymous term
"authentication chain" is defined by RFC 4033 (incorporated by reference
from RFC 6844) as follows:

An alternating sequence of DNS public key
(DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
signed data, with each link in the chain vouching for the next. A
DNSKEY RR is used to verify the signature covering a DS RR and
allows the DS RR to be authenticated. The DS RR contains a hash
of another DNSKEY RR and this new DNSKEY RR is authenticated by
matching the hash in the DS RR. This new DNSKEY RR in turn
authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
this set may be used to authenticate another DS RR, and so forth
until the chain finally ends with a DNSKEY RR whose corresponding
private key signs the desired DNS data. For example, the root
DNSKEY RRset can be used to authenticate the DS RRset for
"example." The "example." DS RRset contains a hash that matches
some "example." DNSKEY, and this DNSKEY's corresponding private
key signs the "example." DNSKEY RRset. Private key counterparts
of the "example." DNSKEY RRset sign data records such as
"www.example." and DS RRs for delegations such as
"subzone.example."

Although the chain ends with a DNSKEY RR in the zone itself, you don't
need to successfully look up that DNSKEY to know that a chain exists:
the presence of a DS record in the parent zone means that the
corresponding DNSKEY RR _has_ to exist. This is made clear by the
totality of RFC4033, particularly sections 5 and 12. So for the
purposes of determining if a zone has a validation/authentication chain
to the ICANN root, the CA should look for the DS record in the parent
zones.

All of this is clear from the relevant DNSSEC RFCs, it's how DNSSEC is
widely understood to work, and is how every DNSSEC implementation
prevents the otherwise trivial downgrade attack. I do not believe there
is any ambiguity in the wording of the BRs, but if there were, it would
have been cleared up by the thread linked above.

Regards,
Andrew

[Andrew Ayer]

[Andrew Ayer]

On Sat, 9 Sep 2017 09:21:30 +0000

Jeremy Rowley via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> Certificate 1 contains a single DNS identifier for
> big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> .
> This DNS name has a CAA resource record set that is too large to fit
> within a single DNS UDP packet, but small enough to fit within a DNS
> TCP packet. The only CAA record containing an issue property is:
>
> big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> .
> IN CAA 0 issue "caatestsuite.com <http://caatestsuite.com> "
>
> Therefore, only caatestsuite.com <http://caatestsuite.com> is
> allowed to issue for this identifier.
>
>
>

> [JR] We only check CAA records with UDP to keep performance good on
> certs with hundreds of SANs. I couldn't find a requirement that
> mandates use of TCP to check CAA records. Should TCP be required?

Jonathan Rudenberg has already addressed this point.

The algorithm specified in section 4 of RFC 6844 clearly supports my
interpretation, although the examples support your interpretation.
Erratum 5065 changes the algorithm to match the examples, but this
erratum has not been incorporated into the BRs yet. I believe that the
algorithm specification carries more normative force than the examples
and should therefore take precedence, making this a misissuance. That
said, I don't think it would be unreasonable for Mozilla to excuse the
misissuance and not require CAs to implement code changes, at least
until the incorporation of Erratum 5065 is resolved.

> Certificate 3 contains a single DNS identifier for
> refused.caatestsuite-dnssec.com

> <http://refused.caatestsuite-dnssec.com> . Attempts to query the CAA

> record for this DNS name result in a REFUSED DNS response. Since
> there is a DNSSEC validation chain from this zone to the ICANN root,

> CAs are not permitted to treat the lookup failure as permission to
> issue.

>
>
>
> [DC] This will always issue. A refusal is treated as a failure.
> Under the BRs a failure is permission to issue if we retry and DNSSec
> is not present. However, although DNSSec is present on the test
> suite's side, we can't see it. Therefore, we get refused (a lookup
> failure), retry (resulting in another lookup failure), followed by a
> DNSSec check (which fails because retrieving the RSSIG record is
> refused). There's no path under which this won't issue because we
> can't see whether DNSSec is present.

You determine whether DNSSEC is present by looking in the
parent zone for the DS record, as I explained in detail in my reply to
Peter Bowen.

Incidentally, Kirk Hall from Entrust posed this exact scenario (DNS
server returning REFUSED) to cabfpub on August 2:

https://cabforum.org/pipermail/public/2017-August/011800.html

In the ensuing thread Phillip Hallam-Baker and Ryan Sleevi both confirmed
that the CA must reject the request, and explained why failing to do so would
open up a downgrade attack.

> Certificate 4 contains a single DNS identifier for
> missing.caatestsuite-dnssec.com
> <http://missing.caatestsuite-dnssec.com> . This DNS name has no CAA
> records, but the zone is missing RRSIG records. Since there is a
> DNSSEC validation chain from this zone to the ICANN root, the DNS
> lookup should fail and this failure cannot be treated by the CA as
> permission to issue.
>
>
>

> [DC] I believe this is properly issued. We retrieved the DNS record
> (no failure) and found no CAA record present. The relevant portion
> of the BRs state: "CAs are permitted to treat a record lookup failure
> as permission to issue if: . the failure is outside the CA's
> infrastructure; . the lookup has been retried at least once; and .

> the domain's zone does not have a DNSSEC validation chain to the

> ICANN root." Although there is a valid DNSSEC chain to the root,
> issuance is still permitted because there was no lookup failure.

It is true the BRs do not explicitly require DNSSEC validation during the
lookup process, and if a CA is not validating DNSSEC during the lookup,
then there would be no lookup failure. However, I would argue that the
requirement to do DNSSEC validation is implied by the requirement
to check for a "DNSSEC validation chain to the ICANN root" should a
lookup fail. Failure to validate DNSSEC during the lookup would remove
all security value from the requirement to check for a DNSSEC validation
chain should a lookup fail. I find it rather unfortunate that any CA
would choose to interpret the BRs this way, especially in light of the above
thread which underscored the need to prevent downgrade attacks.

> Certificate 5 contains a single DNS identifier for
> expired.caatestsuite-dnssec.com
> <http://expired.caatestsuite-dnssec.com> . This DNS name has no CAA

> records, but the zone contains expired RRSIG records. Since there is

> a DNSSEC validation chain from this zone to the ICANN root, the DNS
> lookup should fail and this failure cannot be treated by the CA as
> permission to issue.
>
>
>

> [DC] As with 4, I believe this is properly issued. We retrieved the
> DNS record (no failure). The DNS lacked a CAA record. Although there

> is a valid DNSSEC chain to the root, issuance is still permitted
> because there was no lookup failure.

See response to certificate 4.

> Certificate 6 contains a single DNS identifier for
> blackhole.caatestsuite-dnssec.com
> <http://blackhole.caatestsuite-dnssec.com> . All DNS requests for

> this DNS name will be dropped, causing a lookup failure. Since there

> is a DNSSEC validation chain from this zone to the ICANN root, CAs

> are not permitted to treat the lookup failure as permission to issue.

>
>
>
> [DC] Retrieval of the RSSIG record is failing, which we interpreted
> as the lack of DNSSec. If the DNSSec check times out, we issue
> because 1) The DNS lookup failed, 2) we retried the DNS lookup and it
> failed again, and 3) DNSSec is absent (because the RSSIG record
> lookup failed).

As with the REFUSED test, this should have been rejected because you
know from the DS record in the parent zone that there is a DNSSEC
validation chain to the root.

Regards,
Andrew

[Andrew Ayer]

[Andrew Ayer]

On Sat, 9 Sep 2017 06:57:39 -0400
Jonathan Rudenberg via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

>
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
> > <dev-secur...@lists.mozilla.org> wrote:
> >
> > In all three of these cases, the "domain's zone does not have a
> > DNSSEC validation chain to the ICANN root" -- I requested SOA,
> > DNSKEY, NS, and CAA records types for each zone and in no case did
> > I get a response that had a valid DNSSEC chain to the ICANN root.
>

> This comes down to what exactly “does not have a valid DNSSEC chain”
> means.

As I explained in my reply to Peter, it's not "valid DNSSEC chain", but
rather a "validation chain", which is defined by RFC4033, albeit under
the synonymous term "authentication chain".

> I had assumed that given the reference to DNSSEC in the BRs that the
> relevant DNSSEC RFCs were incorporated by reference via RFC 6844 and
> that DNSSEC validation is required. However, this is not entirely the
> case, using DNSSEC for CAA lookups is only RECOMMENDED in section 4.1

> and explicitly “not required.” Which means this is all pretty
> pointless. The existence or non-existence of DNSSEC records doesn’t

> matter if there is no requirement to use them.

The BRs could arguably be interpreted to not require DNSSEC validation
during lookups, although as I explained in my reply to Jeremy I do not
find this to be a very compelling interpretation.

However, it is not at all ambiguous that a request must be denied if
the lookup fails for non-DNSSEC reasons, if there is DNSSEC validation
chain to the ICANN root. Given the reference to RFC4033 from RFC6844
in the definition of DNSSEC, CAs should be able to figure out what this
means. Therefore, the blackhole and refused certs are unquestionably
misissuances, if not also missing and expired.

Regards,
Andrew

[Andrew Ayer]

[Peter Bowen]

On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer <ag...@andrewayer.name> wrote:
> On Sat, 9 Sep 2017 08:49:01 -0700

> Peter Bowen via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>

>> On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg

>> <jona...@titanous.com> wrote:
>> >
>> >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
>> >> <dev-secur...@lists.mozilla.org> wrote:
>> >>
>> >> In all three of these cases, the "domain's zone does not have a
>> >> DNSSEC validation chain to the ICANN root" -- I requested SOA,
>> >> DNSKEY, NS, and CAA records types for each zone and in no case did
>> >> I get a response that had a valid DNSSEC chain to the ICANN root.
>> >

>> > This comes down to what exactly ___does not have a valid DNSSEC
>> > chain___ means.

>> >
>> > I had assumed that given the reference to DNSSEC in the BRs that
>> > the relevant DNSSEC RFCs were incorporated by reference via RFC
>> > 6844 and that DNSSEC validation is required. However, this is not
>> > entirely the case, using DNSSEC for CAA lookups is only RECOMMENDED

>> > in section 4.1 and explicitly ___not required.___ Which means this is

>> > all pretty pointless. The existence or non-existence of DNSSEC

> to the ICANN root, the CA should look for the DS record in the parent
> zones.

RFC 4033 refers to 4035 for the details on the protocol. In RFC 4035
section 2.4, it says:

A DS RR SHOULD point to a DNSKEY RR that is present in the child's
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
by the corresponding private key. DS RRs that fail to meet these
conditions are not useful for validation, but because the DS RR and
its corresponding DNSKEY RR are in different zones, and because the

Additionally both 4033 and 4035 state that there are four possible
statuses for DNSSEC: Secure, Insecure, Bogus, and Indeterminate. 4033
notes the "signaling mechanism does not distinguish between
indeterminate and insecure states". In the examples I listed, the
resulting state is neither Secure nor Bogus.

> All of this is clear from the relevant DNSSEC RFCs, it's how DNSSEC is
> widely understood to work, and is how every DNSSEC implementation
> prevents the otherwise trivial downgrade attack. I do not believe there
> is any ambiguity in the wording of the BRs, but if there were, it would
> have been cleared up by the thread linked above.

Not every DNSSEC implementation gives the result you claim. I usually
use drill (which is part of the unbound/nsd/ldns/getdns family) to
test. Here is the output for one of your cases:

[ec2-user@ip-10-0-0-18 ~]$ drill -v
drill version 1.7.0 (ldns version 1.7.0)
Written by NLnet Labs.

Copyright (c) 2004-2008 NLnet Labs.
Licensed under the revised BSD license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
[ec2-user@ip-10-0-0-18 ~]$ drill -k /usr/local/etc/unbound/root.key -T
-D -V1 -a refused.caatestsuite-dnssec.com. IN CAA
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 15768 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
[T] com. 86400 IN DS 30909 8 2
e2d3c916f6deeac73294e8268fb5885044a833fc5459588f4a9184cfc41a5766
;; Domain: com.
[T] com. 86400 IN DNSKEY 256 3 8 ;{id = 5528 (zsk), size = 1024b}
com. 86400 IN DNSKEY 257 3 8 ;{id = 30909 (ksk), size = 2048b}
[T] caatestsuite-dnssec.com. 86400 IN DS 58522 5 2
68bbff4ce6d8bbdbb05882f1474efa60805fc6301d8bf08d59f4ab565329072e
;; Domain: caatestsuite-dnssec.com.
[T] caatestsuite-dnssec.com. 60 IN DNSKEY 256 3 5 ;{id = 62745 (zsk),
size = 2048b}
caatestsuite-dnssec.com. 60 IN DNSKEY 257 3 5 ;{id = 58522 (ksk), size = 2048b}
[T] refused.caatestsuite-dnssec.com. 60 IN DS 63016 5 1
a4e5f6421441e881b69961d1157c1851c579d9bf
refused.caatestsuite-dnssec.com. 60 IN DS 63016 5 2
29b0bf92df990ba71a5ed19ed484ad29cb5df037cc0b11faca2f3a384c0ca4cf
;; Domain: refused.caatestsuite-dnssec.com.
;; No DNSKEY record found for refused.caatestsuite-dnssec.com.
[U] No data found for: refused.caatestsuite-dnssec.com. type CAA
;;[S] self sig OK; [B] bogus; [T] trusted
[ec2-user@ip-10-0-0-18 ~]$ echo $?
0

[U] is UNSIGNED. The exit code is 0 (success).

Compare this to a couple of known bad test cases:

[ec2-user@ip-10-0-0-18 ~]$ drill -k /usr/local/etc/unbound/root.key -T
-D -V1 -a sigfail.verteiltesysteme.net. IN A
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
. 172800 IN DNSKEY 256 3 8 ;{id = 15768 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
[T] net. 86400 IN DS 35886 8 2
7862b27f5f516ebe19680444d4ce5e762981931842c465f00236401d8bd973ee
;; Domain: net.
[T] net. 86400 IN DNSKEY 257 3 8 ;{id = 35886 (ksk), size = 2048b}
net. 86400 IN DNSKEY 256 3 8 ;{id = 57899 (zsk), size = 1024b}
[T] verteiltesysteme.net. 86400 IN DS 61908 5 1
3497d121f4c91369e95dc73d8032e688e1abb1fe
verteiltesysteme.net. 86400 IN DS 61908 5 2
2f87866a60c3603f447658ac3ea72baec053b7f9f85fa4b531aabe88b06f5aee
;; Domain: verteiltesysteme.net.
[T] verteiltesysteme.net. 3600 IN DNSKEY 256 3 5 ;{id = 30665 (zsk),
size = 1024b}
verteiltesysteme.net. 3600 IN DNSKEY 257 3 5 ;{id = 61908 (ksk), size = 1024b}
[T] Existence denied: sigfail.verteiltesysteme.net. DS
;; Domain: sigfail.verteiltesysteme.net.
;; No DNSKEY record found for sigfail.verteiltesysteme.net.
[B] sigfail.verteiltesysteme.net. 60 IN A 134.91.78.139
;; Error: Bogus DNSSEC signature
;;[S] self sig OK; [B] bogus; [T] trusted
[ec2-user@ip-10-0-0-18 ~]$ echo $?
5

[ec2-user@ip-10-0-0-18 ~]$ drill -k /usr/local/etc/unbound/root.key -T
-D -V1 -a bogus.d4a16n3.rootcanary.net. IN A
;; Number of trusted keys: 2
;; Domain: .
[T] . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
. 172800 IN DNSKEY 256 3 8 ;{id = 15768 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
[T] net. 86400 IN DS 35886 8 2
7862b27f5f516ebe19680444d4ce5e762981931842c465f00236401d8bd973ee
;; Domain: net.
[T] net. 86400 IN DNSKEY 257 3 8 ;{id = 35886 (ksk), size = 2048b}
net. 86400 IN DNSKEY 256 3 8 ;{id = 57899 (zsk), size = 1024b}
[T] rootcanary.net. 86400 IN DS 64786 8 2
5cd8f125f5487708121a497bd0b1079406add42002b3c195ee0669d2aeb763c9
;; Domain: rootcanary.net.
[T] rootcanary.net. 60 IN DNSKEY 257 3 8 ;{id = 64786 (ksk), size = 1024b}
rootcanary.net. 60 IN DNSKEY 256 3 8 ;{id = 25188 (zsk), size = 1024b}
[T] d4a16n3.rootcanary.net. 60 IN DS 40569 16 4
57c663467f4e3e0b5207da75420de177ce699fa02a50b69551a481ff2d5d655b25f8a955494f5cea84e3e485c3aa5ac0
;; Domain: d4a16n3.rootcanary.net.
[B] d4a16n3.rootcanary.net. 60 IN DNSKEY 257 3 16 ;{id = 40569 (ksk), size = 0b}
;; No DS for bogus.d4a16n3.rootcanary.net.;; Domain:
bogus.d4a16n3.rootcanary.net.
;; No DNSKEY record found for bogus.d4a16n3.rootcanary.net.
[B] bogus.d4a16n3.rootcanary.net. 60 IN A 145.97.20.17
;; Error: Unknown cryptographic algorithm
;;[S] self sig OK; [B] bogus; [T] trusted
[ec2-user@ip-10-0-0-18 ~]$ echo $?
5

Thanks,
Peter

[Peter Bowen]

[Andrew Ayer]

On Sat, 9 Sep 2017 13:14:29 -0700

I'm not sure what point you are trying to make. Are you disputing that
expired.caatestsuite-dnssec.com, missing.caatestsuite-dnssec.com,
blackhole.caatestsuite-dnssec.com, and refused.caatestsuite-dnssec.com
have validation chains to the root?

They certainly meet the definition of bogus as defined in 4033, as
there is a "secure delegation indicating that subsidiary data is signed"
(the DS record), and the "response fails to validate for some reason".

> > All of this is clear from the relevant DNSSEC RFCs, it's how DNSSEC
> > is widely understood to work, and is how every DNSSEC implementation
> > prevents the otherwise trivial downgrade attack. I do not believe
> > there is any ambiguity in the wording of the BRs, but if there
> > were, it would have been cleared up by the thread linked above.
>
> Not every DNSSEC implementation gives the result you claim. I usually
> use drill (which is part of the unbound/nsd/ldns/getdns family) to
> test. Here is the output for one of your cases:

drill is buggy and insecure. Obviously, such implementations can
be found. Note that drill is just a "debugging/query" tool, not a
resolver you would actually use in production. You'll find that the
production-grade resolver from that family (unbound) correctly reports
an error when you try to query the CAA record for
refused.caatestsuite-dnssec.com: https://unboundtest.com/

Regards,
Andrew

[Peter Bowen]

On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer <ag...@andrewayer.name> wrote:
>
> drill is buggy and insecure. Obviously, such implementations can
> be found. Note that drill is just a "debugging/query" tool, not a
> resolver you would actually use in production. You'll find that the
> production-grade resolver from that family (unbound) correctly reports
> an error when you try to query the CAA record for
> refused.caatestsuite-dnssec.com: https://unboundtest.com/

Just as I received this, I finished testing with unbound, to see what
it does. See the results below. For your blackhole, servfail, and
refused cases it clearly says insecure, not bogus.

[ec2-user@ip-10-0-0-18 ~]$ unbound-host -h
Usage: unbound-host [-vdhr46] [-c class] [-t type] hostname
[-y key] [-f keyfile] [-F namedkeyfile]
[-C configfile]
Queries the DNS for information.
The hostname is looked up for IP4, IP6 and mail.
If an ip-address is given a reverse lookup is done.
Use the -v option to see DNSSEC security information.
-t type what type to look for.
-c class what class to look for, if not class IN.
-y 'keystring' specify trust anchor, DS or DNSKEY, like
-y 'example.com DS 31560 5 1 1CFED8478...'
-D DNSSEC enable with default root anchor
from /usr/local/etc/unbound/root.key
-f keyfile read trust anchors from file, with lines as -y.
-F keyfile read named.conf-style trust anchors.
-C config use the specified unbound.conf (none read by default)
-r read forwarder information from /etc/resolv.conf
breaks validation if the forwarder does not do DNSSEC.
-v be more verbose, shows nodata and security.
-d debug, traces the action, -d -d shows more.
-4 use ipv4 network, avoid ipv6.
-6 use ipv6 network, avoid ipv4.
-h show this usage help.
Version 1.6.5
BSD licensed, see LICENSE in source package for details.
Report bugs to unboun...@nlnetlabs.nl
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t CAA -D -f
/usr/local/etc/unbound/root.key expired.caatestsuite-dnssec.com.
expired.caatestsuite-dnssec.com. has no CAA record (BOGUS (security failure))
validation failure <expired.caatestsuite-dnssec.com. CAA IN>:
signature expired from 96.126.110.12 for key
expired.caatestsuite-dnssec.com. while building chain of trust
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t CAA -D -f
/usr/local/etc/unbound/root.key missing.caatestsuite-dnssec.com.
missing.caatestsuite-dnssec.com. has no CAA record (BOGUS (security failure))
validation failure <missing.caatestsuite-dnssec.com. CAA IN>: no
signatures from 96.126.110.12 for key missing.caatestsuite-dnssec.com.
while building chain of trust
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t CAA -D -f
/usr/local/etc/unbound/root.key blackhole.caatestsuite-dnssec.com.
Host blackhole.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (insecure)
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t CAA -D -f
/usr/local/etc/unbound/root.key servfail.caatestsuite-dnssec.com.
Host servfail.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (insecure)
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t CAA -D -f
/usr/local/etc/unbound/root.key refused.caatestsuite-dnssec.com.
Host refused.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (insecure)
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t NS -D -f
/usr/local/etc/unbound/root.key blackhole.caatestsuite-dnssec.com.
Host blackhole.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (insecure)
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t NS -D -f
/usr/local/etc/unbound/root.key servfail.caatestsuite-dnssec.com.
Host servfail.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (insecure)
[ec2-user@ip-10-0-0-18 ~]$ unbound-host -v -t NS -D -f
/usr/local/etc/unbound/root.key refused.caatestsuite-dnssec.com.
Host refused.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (insecure)

[Andrew Ayer]

On Sat, 9 Sep 2017 13:53:52 -0700

Peter Bowen via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer <ag...@andrewayer.name>
> wrote:
> >
> > drill is buggy and insecure. Obviously, such implementations can
> > be found. Note that drill is just a "debugging/query" tool, not a
> > resolver you would actually use in production. You'll find that the
> > production-grade resolver from that family (unbound) correctly
> > reports an error when you try to query the CAA record for
> > refused.caatestsuite-dnssec.com: https://unboundtest.com/
>
> Just as I received this, I finished testing with unbound, to see what
> it does. See the results below. For your blackhole, servfail, and
> refused cases it clearly says insecure, not bogus.

That is very clearly against RFC4033, which says defines Insecure as:

The validating resolver has a trust anchor, a chain
trust, and, at some delegation point, signed proof of the
non-existence of a DS record. This indicates that subsequent
branches in the tree are provably insecure. A validating resolver
may have a local policy to mark parts of the domain space as
insecure.

There is no "signed proof of the non-existence of a DS record" for
blackhole, servfail, and refused, so it cannot possibly be insecure.

Regards,
Andrew

[Peter Bowen]

I just found another tool that does checks and has a similar but
distinct response set:

https://portfolio.sidnlabs.nl/check/expired.caatestsuite-dnssec.com/CAA (bogus)
https://portfolio.sidnlabs.nl/check/missing.caatestsuite-dnssec.com/CAA (bogus)
https://portfolio.sidnlabs.nl/check/blackhole.caatestsuite-dnssec.com/CAA
(error)
https://portfolio.sidnlabs.nl/check/servfail.caatestsuite-dnssec.com/CAA (error)
https://portfolio.sidnlabs.nl/check/refused.caatestsuite-dnssec.com/CAA (error)
https://portfolio.sidnlabs.nl/check/sigfail.verteiltesysteme.net/A (bogus)
https://portfolio.sidnlabs.nl/check/bogus.d4a16n3.rootcanary.net/A (insecure)
https://portfolio.sidnlabs.nl/check/www.google.com/A (insecure)
https://portfolio.sidnlabs.nl/check/www.dnssec-failed.org/A (bogus)

Given that there does not seem to be a consistent definition on how
"broken" DNSSEC should be handled, I think it is reasonable that CAs
should be given benefit of the doubt on the broken DNSSEC tests.

Thanks,
Peter

[Andrew Ayer]

According to https://portfolio.sidnlabs.nl/form this tool is just a web
frontend for libunbound, so it suffers from the same libunbound bug (reported
here: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439).

> Given that there does not seem to be a consistent definition on how
> "broken" DNSSEC should be handled, I think it is reasonable that CAs
> should be given benefit of the doubt on the broken DNSSEC tests.

I believe the following two facts are not disputed:

1. refused.caatestsuite-dnssec.com, servfail.caatestsuite-dnssec.com,
and blackhole.caatestsuite-dnssec.com cause lookup failures.

2. The Baseline Requirements permit CAs to treat a lookup failure as
permission to issue only when "the domain's zone does not have a DNSSEC
validation chain to the ICANN root."

What is disputed is whether these three domains' zones have a DNSSEC
validation chain to the ICANN root. Considering the definition given
in RFC 4033, incorporated by reference from RFC 6844, I say that they
do, and that the CA is capable of determining this. What about these
rules is so unclear it justifies giving CAs the benefit of the doubt
for issuing for these three FQDNs? I do not believe the existence of a
single DNS implementation that violates RFC 4033 and 4035 by neglecting
to consider a response bogus in some situations is evidence of
unclarity as to what constitutes a validation chain.

Regards,
Andrew

[Jeremy Rowley]

Thanks Gerv - we're working on a patch today for it. We'll also revoke the
cert today.

-----Original Message-----
From: Gervase Markham [mailto:ge...@mozilla.org]
Sent: Monday, September 11, 2017 9:12 AM
To: Jeremy Rowley <jeremy...@digicert.com>;
mozilla-dev-s...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

On 09/09/17 10:21, Jeremy Rowley wrote:
> Certificate 1 contains a single DNS identifier for
> big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> . This
> DNS name has a CAA resource record set that is too large to fit within
> a single DNS UDP packet, but small enough to fit within a DNS TCP
> packet. The only CAA record containing an issue property is:
>
> big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> . IN
> CAA 0 issue "caatestsuite.com <http://caatestsuite.com> "
>
> Therefore, only caatestsuite.com <http://caatestsuite.com> is allowed
> to issue for this identifier.

>From the discussion so far, I'd say that this one is clearly a misissuance,
and needs treating as one. (I see this as a clever vuln, not as CA
implementation incompetence.)

The jury is still out on the CNAME and DNSSEC-based reports.

Gerv

[Jeremy Rowley]

Not saying we implemented DNSSEC checking correctly, but I don't think the requirements are as clear as you present them.

The BRs state that:
" CAs are permitted to treat a record lookup failure as permission to issue if:
• the failure is outside the CA's infrastructure;
• the lookup has been retried at least once; and
• the domain's zone does not have a DNSSEC validation chain to the ICANN root."

That's the entire corpus of information related to DNSSEC in the BRs. Under 4 and 5, we successfully returned a DNS record. The lookup didn’t fail so the sentence "the domain's zone does not have a DNSSEC validation chain to the ICANN root" doesn't apply. There is no need to check the DNSSEC validation chain in this case.

For 3 and 6:
RFC 4033:
1) Is not referenced in the BRs
2) Does not define domain's zone
3) Does not reference a "validation chain" (but does define authentication chain as you noted)
4) Does not mention an ICANN root
5) Is only a footnote in RFC 6844

Although most of these are straight forward without being defined, the culmination of semi-loose specifications makes for one very loose specification at the CAB Forum level, especially where programs like drill apparently did DNSSEC checking wrong.

Of course, we would like to properly check DNSSEC (or at least check it more properly) so I'm interested to hear your opinion on whether this works as a fix:
1) Checking the entire DNSSEC chain was incredibly slow, causing the certs to take 10 sec plus to issue. We figured checking RRSIG removed this delay by simply checking whether DNSSEC exists. If DNSSEC exists and we failed to return a DNS record, we'll just block the cert.
2) Instead of checking the DNSSEC chain, could we simply check the DNSKEY RR at the parent? If the DNS RRSet exists at the parent, we will simply refuse the cert issuance. This way we avoid the super long issuance times while still respecting DNSSEC requirements.

Thanks a ton for the discussion on this.
Jeremy

-----Original Message-----
From: Andrew Ayer [mailto:ag...@andrewayer.name]
Sent: Saturday, September 9, 2017 1:01 PM
To: Jonathan Rudenberg <jona...@titanous.com>
Cc: Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org>; Peter Bowen <pzb...@gmail.com>; mozilla-dev-s...@lists.mozilla.org; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 06:57:39 -0400

Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

>
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy

> > <dev-secur...@lists.mozilla.org> wrote:
> >
> > In all three of these cases, the "domain's zone does not have a
> > DNSSEC validation chain to the ICANN root" -- I requested SOA,
> > DNSKEY, NS, and CAA records types for each zone and in no case did I
> > get a response that had a valid DNSSEC chain to the ICANN root.
>

> This comes down to what exactly “does not have a valid DNSSEC chain”
> means.

As I explained in my reply to Peter, it's not "valid DNSSEC chain", but rather a "validation chain", which is defined by RFC4033, albeit under the synonymous term "authentication chain".

> I had assumed that given the reference to DNSSEC in the BRs that the
> relevant DNSSEC RFCs were incorporated by reference via RFC 6844 and
> that DNSSEC validation is required. However, this is not entirely the
> case, using DNSSEC for CAA lookups is only RECOMMENDED in section 4.1

> and explicitly “not required.” Which means this is all pretty
> pointless. The existence or non-existence of DNSSEC records doesn’t

> matter if there is no requirement to use them.

[Jeremy Rowley]

[Nick Lamb]

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 and 5, we successfully returned a DNS record. The lookup didn’t fail so the sentence "the domain's zone does not have a DNSSEC validation chain to the ICANN root" doesn't apply. There is no need to check the DNSSEC validation chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at all? If Honest Achmed is asked to issue for example.com, he can do a plain (non DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue on that basis, never needing to investigate whether example.com has DNSSEC enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be good to understand which CAs are vulnerable in this way. Of course, even if you know this it's pointless to exclude them using CAA, they'll accept a spoofed answer...

[Jeremy Rowley]

I think that's the opposite of what I'm saying. CAs don't need to do DNSSEC provided 1) they don't want to issue certs where DNSSEC is implemented and 2) the CAA record check times out, and 3) there is a way to check if DNSSEC is present without doing the entire chain validation. #3 is what I'm not sure of.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote:

> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 and 5, we successfully returned a DNS record. The lookup didn’t fail so the sentence "the domain's zone does not have a DNSSEC validation chain to the ICANN root" doesn't apply. There is no need to check the DNSSEC validation chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at all? If Honest Achmed is asked to issue for example.com, he can do a plain (non DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue on that basis, never needing to investigate whether example.com has DNSSEC enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be good to understand which CAs are vulnerable in this way. Of course, even if you know this it's pointless to exclude them using CAA, they'll accept a spoofed answer...

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Jeremy Rowley]

For a little more context, the idea is that we can speed up the CAA check for all customers while working with those who have DNSSEC to make sure they aren't killing performance. If there's a way to group them easily into buckets (timeout + quick does DNSSEC exist check), working on improving the experience for that particular set of customers is easier. That bucket can then be improved later.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, September 11, 2017 2:56 PM
To: Nick Lamb <tiala...@gmail.com>; mozilla-dev-s...@lists.mozilla.org
Subject: RE: CAA Certificate Problem Report

I think that's the opposite of what I'm saying. CAs don't need to do DNSSEC provided 1) they don't want to issue certs where DNSSEC is implemented and 2) the CAA record check times out, and 3) there is a way to check if DNSSEC is present without doing the entire chain validation. #3 is what I'm not sure of.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote:

> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 and 5, we successfully returned a DNS record. The lookup didn’t fail so the sentence "the domain's zone does not have a DNSSEC validation chain to the ICANN root" doesn't apply. There is no need to check the DNSSEC validation chain in this case.

[Jonathan Rudenberg]

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> For a little more context, the idea is that we can speed up the CAA check for all customers while working with those who have DNSSEC to make sure they aren't killing performance. If there's a way to group them easily into buckets (timeout + quick does DNSSEC exist check), working on improving the experience for that particular set of customers is easier. That bucket can then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple CAs and the fact that it’s optional in the CAA RFC, what do you think about proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan

[Jeremy Rowley]

I would support that. I can't recall why it's in there.

-----Original Message-----
From: Jonathan Rudenberg [mailto:jona...@titanous.com]
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

[Ryan Sleevi]

That seems like very poor logic and justification.

Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
literally years now, perhaps it's worth asking why CAs are only now
discovering issues. That is, is the only reason we're discovering issues
because CAs waited for the last possible moment? If so, why.

Because they didn't write test suites? If not, why not? If so, what were
they?

I think arguments that suggest that failing to do the right thing makes it
OK to do the wrong thing are the worst arguments to make :)

On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I would support that. I can't recall why it's in there.
>
> -----Original Message-----
> From: Jonathan Rudenberg [mailto:jona...@titanous.com]
> Sent: Monday, September 11, 2017 3:19 PM
> To: Jeremy Rowley <jeremy...@digicert.com>
> Cc: mozilla-dev-s...@lists.mozilla.org

> Subject: Re: CAA Certificate Problem Report
>
>

> > On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > For a little more context, the idea is that we can speed up the CAA
> check for all customers while working with those who have DNSSEC to make
> sure they aren't killing performance. If there's a way to group them
> easily into buckets (timeout + quick does DNSSEC exist check), working on
> improving the experience for that particular set of customers is easier.
> That bucket can then be improved later.
>
> Given the disaster that DNSSEC+CAA has been over the past few days for
> multiple CAs and the fact that it’s optional in the CAA RFC, what do you
> think about proposing a ballot to remove the DNSSEC requirement from the
> BRs entirely?
>
> Jonathan

[Jeremy Rowley]

Well, we are checking CAA and DNSSEC per our implementation. Looks great on our side and against our tests. Some individuals disagree though.

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Monday, September 11, 2017 3:42 PM
To: Jeremy Rowley <jeremy...@digicert.com>; Jonathan Rudenberg <jona...@titanous.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

That seems like very poor logic and justification.



Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for literally years now, perhaps it's worth asking why CAs are only now discovering issues. That is, is the only reason we're discovering issues because CAs waited for the last possible moment? If so, why.



Because they didn't write test suites? If not, why not? If so, what were they?



I think arguments that suggest that failing to do the right thing makes it OK to do the wrong thing are the worst arguments to make :)

On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

I would support that. I can't recall why it's in there.

-----Original Message-----
From: Jonathan Rudenberg [mailto:jona...@titanous.com <mailto:jona...@titanous.com> ]
Sent: Monday, September 11, 2017 3:19 PM

To: Jeremy Rowley <jeremy...@digicert.com <mailto:jeremy...@digicert.com> >
Cc: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:
>
> For a little more context, the idea is that we can speed up the CAA check for all customers while working with those who have DNSSEC to make sure they aren't killing performance. If there's a way to group them easily into buckets (timeout + quick does DNSSEC exist check), working on improving the experience for that particular set of customers is easier. That bucket can then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple CAs and the fact that it’s optional in the CAA RFC, what do you think about proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan
_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Jonathan Rudenberg]

> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> That seems like very poor logic and justification.
>
> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
> literally years now, perhaps it's worth asking why CAs are only now
> discovering issues. That is, is the only reason we're discovering issues
> because CAs waited for the last possible moment? If so, why.

I think the BR clause that brings DNSSEC in is poorly drafted. It seems like the intent may be to require full DNSSEC validation for CAA lookups, but that’s not what it says. I don’t think the issues under discussion have anything to do with the last moment. There appear to be significant differences in understanding, which were not discussed publicly until now. The ideal path here would have been for CAs to consult with the community about the interpretation and implementation details of this clause well before it came into force.

Additionally, it may be a stretch to say that DNSSEC in the context of CAA has been discussed extensively. I’m not familiar with relevant discussions that are not indexed by Google, but when I researched this I only found a few exchanges about this specific requirement on the public mailing list.

https://cabforum.org/pipermail/public/2016-November/008831.html
https://cabforum.org/pipermail/public/2017-February/009732.html

> I think arguments that suggest that failing to do the right thing makes it
> OK to do the wrong thing are the worst arguments to make :)

My argument is not that it’s okay to do the wrong thing. Instead, I think it’s worth evaluating the DNSSEC requirement to decide whether it should continue to be defined as "the right thing” in the BRs. I did not see any such analysis on cabfpub.

Jonathan

[Jonathan Rudenberg]

> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

>
> On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>>> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>>
>>> That seems like very poor logic and justification.
>>>
>>> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
>>> literally years now, perhaps it's worth asking why CAs are only now
>>> discovering issues. That is, is the only reason we're discovering issues
>>> because CAs waited for the last possible moment? If so, why.
>>
>> I think the BR clause that brings DNSSEC in is poorly drafted.
>
>

> Why?

As written, it’s not clear what the point is, as I describe below. If the intent was to require DNSSEC validation, it should say that clearly.

>> Additionally, it may be a stretch to say that DNSSEC in the context of CAA
>> has been discussed extensively.
>
>

> I'm not sure I understand why you feel some special discussion is or was
> necessary, given the discussion that occurred in IETF on this. That is, are
> you asserting that these issues - such as CAs not even checking CAA - are
> because of the ballot language?

I’m only talking about the DNSSEC-related issues here, I’m not aware of any CAs that are not or were not checking CAA due to DNSSEC.

Some CAs have interpreted this clause to not require DNSSEC validation when doing CAA queries, do you believe that interpretation is valid?

My interpretation is that DNSSEC validation is required to the point to the domain’s zone (but not to the CAA record set itself) if a CA wants to treat a record lookup failure as permission to issue. If the goal is to address the relevant security considerations in RFC 6844 with DNSSEC, this appears to leave a pretty gaping hole where a CA could:

1) not implement DNSSEC at all, and treat lookup failures as issuance-blocking errors; or
2) implement enough DNSSEC to decide if a zone has a “validation chain” without ever validating the CAA queries themselves

Thus, the clause as I interpret it only prevents a specific attack that drops CAA query answers and doesn't provide any authenticity or integrity guarantees. Instead of dropping an answer, an attacker could just replace the answer with one that they want.

> I’m not familiar with relevant discussions that are not indexed by Google,
>> but when I researched this I only found a few exchanges about this specific
>> requirement on the public mailing list.
>
>

> This was discussed at nearly every single F2F since late 2013/early 2014.
> The DNSSEC discussion was very much part of the IETF discussions.
>
> What discussions do you feel should have happened, but didn’t?

So far I’ve been working of the interpretation above, and so I’ve been trying to understand why DNSSEC is brought in while not addressing any meaningful security considerations.

>>> I think arguments that suggest that failing to do the right thing makes
>> it
>>> OK to do the wrong thing are the worst arguments to make :)
>>
>> My argument is not that it’s okay to do the wrong thing. Instead, I think
>> it’s worth evaluating the DNSSEC requirement to decide whether it should
>> continue to be defined as "the right thing” in the BRs. I did not see any
>> such analysis on cabfpub.
>
>

> I'm surprised to even see the suggestion that it isn't. Do you feel the
> security considerations are insufficiently documented in the CAA RFC? Do
> you feel it's not sufficiently obvious the risks of not using DNSSEC?

The security considerations are clear, and if properly implemented, DNSSEC would help there. These security considerations also apply to all online domain validation methods, and DNSSEC isn’t required there, so I’m not yet convinced by this argument.

What isn’t clear is whether DNSSEC should be deployed at all. There have been many large outages caused by DNSSEC[0], the tooling is horrible, weak crypto is rampant throughout the system, and the specification is extraordinarily complex. The footgun potential is greater than HPKP in scale, and the end result is something that even if deployed widely won’t even protect the average user from spoofed DNS answers on open WiFi. So, no, I’m not convinced that it’s the right thing.

Jonathan

[0] https://ianix.com/pub/dnssec-outages.html

[Nick Lamb]

I'm struggling to get my head around what you're asking for. I think you're seriously asking if there's a way to skip all the actual security of DNSSEC and get a secure answer anyway?

No. The answer is "No". If you're comfortable with answers that might be lies, you can skip DNSSEC entirely. Otherwise you need to use DNSSEC to get either a signed, true answer, or signed proof there is no signed answer for the question you had (in which case you might choose to accept whatever answer you do get knowing it might not be true but at least you tried), or an error.

Relying on an answer that might be a lie to tell you whether the answers you're getting might be lies is pointless. Literally futile.

[Adriano Santoni]

+1

Il 11/09/2017 23:28, Jeremy Rowley via dev-security-policy ha scritto:
> I would support that. I can't recall why it's in there.
>
> -----Original Message-----
> From: Jonathan Rudenberg [mailto:jona...@titanous.com]
> Sent: Monday, September 11, 2017 3:19 PM
> To: Jeremy Rowley <jeremy...@digicert.com>

> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: CAA Certificate Problem Report
>
>

>> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> For a little more context, the idea is that we can speed up the CAA check for all customers while working with those who have DNSSEC to make sure they aren't killing performance. If there's a way to group them easily into buckets (timeout + quick does DNSSEC exist check), working on improving the experience for that particular set of customers is easier. That bucket can then be improved later.
> Given the disaster that DNSSEC+CAA has been over the past few days for multiple CAs and the fact that it’s optional in the CAA RFC, what do you think about proposing a ballot to remove the DNSSEC requirement from the BRs entirely?
>
> Jonathan
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 11/09/17 22:28, Jeremy Rowley wrote:
> I would support that. I can't recall why it's in there.

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.

I also seem to recall that the intent was not to require that CAs do
proper DNSSEC lookups for all CAA requests as long as they were happy to
fail closed in the presence of DNSSEC. This again has the above implicit
assumption baked into it.

Gerv

[Nick Lamb]

Gerv, rather than start by digging into the specific technical details, let me ask a high level question.

Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA record saying to only permit the non-existent Gotham Certificates gotham.example to issue.

You say you don't want CAs to need to implement DNSSEC. But you also don't want them issuing for my domain. How did you imagine this circle would be squared?

If a CA doesn't implement DNSSEC bad guys can send them a forged answer to any query and they'll believe it. We might say to ourselves "Oh, the CA should take reasonable precautions to prevent that" but er, the reasonable precaution is to implement DNSSEC.

The arguments against DNSSEC in ordinary clients end up being about practicality, it would be difficult and costly. Ok. But running a public CA is already difficult and costly. Trustworthiness is not cheap.

I've also seen a few complaints about DNSSEC being slow at scale. As I understand it Let's Encrypt used DNSSEC at scale from its inception. Whether they're really "biggest" in some sense is debatable, but they're definitely not a boutique outfit, if they can do it then it's clearly not impossible.

[Matthew Hardeman]

I concur in full with Nick Lamb's comments and positions on this matter.

There is no reasonable short cut to actually doing the DNSSEC thing if we want to usefully intertwine those technologies at all.

There IS significant benefit in enforcing complete DNSSEC validation for (all) the domain validation DNS queries where DNSSEC has been configured for the relevant zones.

This is especially the case for CAA records, which have an explicit security function: controlling, at a minimum, who may issue publicly trusted certificates for a given FQDN.

I will note that from the software development perspective, I concede that many of the DNS query APIs don't surface (at least in a friendly way) exactly what the nature of the DNSSEC validation failure is or at what layer of delegation the validation fails.

My position is that ultimately, that doesn't really matter: If a CA wanted a quick and easy path to differentiating whether a domain has a DNSSEC problem or a CAA problem, chase the queries from the root down both with DNSSEC validation on and with DNSSEC validation off. If no errors arise (because DNSSEC is not configured, etc) then rely on the CAA records alone.

If, however, a DNSSEC validated response comes back but errors exist on DNSSEC enabled queries for the CAA records, presume there's a DNSSEC problem of some sort and let the DNS / site admin work out the specific failure. Alternatively, do further digging for the mode of failure outside of the issuance path, in a separate after-adverse-decisioning debug / diagnostic path.

It is undeniable that DNSSEC validated query resolution takes longer than queries without DNSSEC. Regardless, these are not terribly lengthy. If the finding is that they are lengthy, reduce the local max timeout for whatever phases are taking too long.

I'm having trouble understanding how even several seconds of (asynchronous) delay can be a factor of great concern for a commercial CA. I would assume that all kinds of checks are going on in parallel with callbacks hitting and the certificate advancing to signing when all the necessary callbacks have updated the test status to good. I'm certain that one absolutely could build such a set of asynchronous work queues which would perform tests in a significantly parallel fashion for a great many pending certificates and then push each pending certificate to the actual signer in the moment that the last callback for a given required test posts GOOD on a particular pending issue. Let them process out-of-order prior to hitting the signer, submitting to the final FIFO signing queue in the instant that the last test which clears the issuance decisions transitions to positive.

I'd like to comment that DNSSEC and CAA in combination are, to my mind, the only presently available solution of an unambiguous nature for prevention of fraudulent domain-validation success results in a world where a significantly connected BGP participant might hijack ones IP space. On this basis, I assert that there is real and distinct value in enforcing the sanctity of CAA or sanctity of lack of CAA via DNSSEC validation wherever DNSSEC has been configured.

Without managing to hoodwink the TLD registry or associated TLD registrar for a domain, there is no way for a successful IP space hijack to yield manipulated results to DNS queries answered by authoritatives in said hijacked IP space -- if and only if DNSSEC validation is performed.

I put forth that the security of the root zone delegation, and delegation from the TLD registrar/registry to the authoritative zone IS or CAN BE far more secure than DNS queries without cryptographic validation in a world where the IP space underpinning an authoritative DNS server can be (fairly) easily hijacked.

For what it's worth, I'd also LOVE to see an extension option to CAA records which standardize ways of indicating acceptable domain validation methodologies along with acceptable CAs. For example, it would be nice to be able to say "Allow only Let's Encrypt to issue; Allow issuance only when domain validation mechanism relies exclusively upon DNS". In this environment, even if someone hijacks the IP space of a web server within the domain, they are unable to get a certificate issued because they can't skip the CAA and the DNSSEC is keeping the issuance from occurring because it requires a DNS proof for issuance, rather than allowing the random-verification-content-in-a-well-known-url validation.

Just my thoughts on the matter...

Thanks,

Matt Hardeman

[Matthew Hardeman]

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

[Jakob Bohm]

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

[Gervase Markham]

On 13/09/17 23:57, Matthew Hardeman wrote:
> This is especially the case for CAA records, which have an explicit security function: controlling, at a minimum, who may issue publicly trusted certificates for a given FQDN.

I'd be interested in your engagement on my brief threat modelling; it
seems to me that DNSSEC only adds value in the scenario where an
attacker has some control of CA Foo's issuance process, but not enough
to override the CAA check internally, but it also has enough control of
the network (either at the target, or at the CA) to spoof DNS responses
to defeat CAA. That seems on the surface like a rare scenario.

Gerv

[Nick Lamb]

On Tuesday, 19 September 2017 14:02:36 UTC+1, Gervase Markham wrote:
> I'd be interested in your engagement on my brief threat modelling; it
> seems to me that DNSSEC only adds value in the scenario where an
> attacker has some control of CA Foo's issuance process, but not enough
> to override the CAA check internally, but it also has enough control of
> the network (either at the target, or at the CA) to spoof DNS responses
> to defeat CAA. That seems on the surface like a rare scenario.

The latter part sounds correct. The first part is definitely inaccurate.

An attacker only has to _prefer_ one particular CA for any reason, it needn't be that they can control issuance. Off the top of my head reasons to prefer a particular CA for an attack _despite_ no control over issuance might include:

* This CA offers a particular validation method we can exploit. For example they accept Domain Authorization Documents and we are expert forgers, we anticipate our documents will be entirely convincing but of course we can't submit them to a CA which doesn't offer this method. Or, we have a trick where we can intercept email for a domain unnoticed, but we cannot use this to validate with a CA which doesn't offer email validation.

* This CA is known not to treat our target as "High Value" while others do. If we try another CA they will flag the application for scrutiny and a human may spot that it is suspicious and notify the target.

* This CA doesn't CT log, or does so only belatedly, buying us more time before an alert target will realise what we're doing compared to a CA which logs all issuances immediately.

* This CA is notoriously slow to react to problem reports, again buying us more time to use the certificate before they revoke it and admit what happened compared to a CA which is proactive and would engage immediately.

* This CA's audit logging is poor, so that when our attack succeeds the police and other investigators will find the trail of evidence is inadequate and it's difficult to track the attackers down and prosecute them. A better CA might give investigators a hot trail and lead to us being caught.

* This CA is located in a jurisdiction that's especially inconvenient for the target. The target's usual CA probably speaks their language, operates in a similar timezone, maybe has extradition treaties and mutual co-operation rules that will help if there's a crime, but we can choose one that's as difficult as possible.

* This CA is trusted by a particular application or device beyond the scope of the Web PKI so that we can leverage an attack on Web PKI assets to actually break something far more important, payment gateways, life support, whatever. Other CAs are useless for this type of attack because there is no reason for them to be trusted in these other applications.

CAA isn't a magic "fix" for any of these, but it follows the principle of least privilege. Why let every CA in the world issue for example.com if we, as example.com, are confident we only want to use Honest Achmed? If we change our minds (perhaps after Achmed's dubious personnel structures are revealed) we can just update the CAA record, no trouble.

[Gervase Markham]

On 19/09/17 14:58, Nick Lamb wrote:
> An attacker only has to _prefer_ one particular CA for any reason,

<snip>

Yep, fair.

Gerv

[Matthew Hardeman]

On Tuesday, September 19, 2017 at 8:02:36 AM UTC-5, Gervase Markham wrote:

> I'd be interested in your engagement on my brief threat modelling; it
> seems to me that DNSSEC only adds value in the scenario where an
> attacker has some control of CA Foo's issuance process, but not enough
> to override the CAA check internally, but it also has enough control of
> the network (either at the target, or at the CA) to spoof DNS responses
> to defeat CAA. That seems on the surface like a rare scenario.

The situation involves somewhat more / different risks than you've described.

A (properly positioned -- as further described below) prospective attacker need only be aware of any particular CA which might issue a domain validation certificate upon his/her request, said CA having been chosen because of support of an automated domain validation mechanism which relies exclusively upon DNS queries and which fails to enforce the full integrity of DNSSEC validation despite the target FQDN having been configured for DNSSEC.

In fairness, the risk that I outline below is principally a risk that has not been previously mitigated in the general issuance of DV certificates historically. As such, the risk illuminated here might best be described as a "reduction in functional security value and/or reduction in potential functional security value derived from CAA checking". What I mean to illustrate is that for the first time, CAA checking in combination with strict enforcement of DNSSEC validation -- including strict enforcement of securely discovering whether or not a particular zone should be DNSSEC signed -- offers the opportunity to introduce a strong cryptographic assurance that a Domain Validated certificate issued for a properly DNSSEC signed and CAA implementing domain was, in fact, validated without data tampering from the proper name servers regardless of any IP address hijack or well positioned man-in-the-middle between the CA's validation infrastructure and the certificate requestor.

Some significant academic work has recently been performed in the area of the danger of specific BGP hijacks of IP space for purposes of improperly acquiring DV certificates for chosen target domains. See, for example: https://www.princeton.edu/~pmittal/publications/bgp-tls-hotpets17

Additionally, on the basis of this and other work, significant advancement toward certain field mitigations of these threats is beginning to advance. See: https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955

These field mitigations, such as redundant checks of the domain validation from multiple geo-distinct network vantage points certainly reduce the risk, particularly they reduce the risk of super-quiet narrowly scoped, geographically specific network space hijacks which might go largely unnoticed.

Those techniques will be significantly more limited and thus significantly less effective as pertains quite brief (seconds to minutes) but global, far less subtle IP space hijacks.

Risk illustration by positing a hypothetical scenario in which:

My evil reverse twin (see various strange ramblings of Chuck Tingle for reference) seeks to improperly acquire a certificate for ipifony.net and/or subdomains thereof.

Said evil party is aware that ipifony.net is DNSSEC signed but knows of a CA that: doesn't DNSSEC validate and that connects to the broader internet via one or more upstreams that he can influence to believe that his systems are the paths to the IP space of the zone's authoritative DNS servers, even if only briefly.

In less than a minute total, the certificate can be had.

A party well positioned and skilled in the art (the well positioned part, at least, is probably far less expensive than many would suspect) advertises the two /24s which contain the ipifony.net authoritative DNS servers. Just needs to be an entity well peered at one of the nation's several significant IXP hosting carrier hotels. Again, costs less than one would imagine.

Request for automated fulfillment of DV cert is submitted.

CA performs DNS queries, speaking with fake / substitute DNS servers. Confirms lack of CAA and proper TXT or CNAM records to authenticate DV issuance.

CA issues certificate.

Hijack advertisement withdrawn.

Alternatively, if issuance could happen only after CAA checking with DNSSEC validation enforced, this IP space hijack will have been thwarted (assuming I have managed my domain configuration at the registrar securely and that I have maintained proper custody and control over my DNSSEC signing keys). With DNSSEC validation on, there is no way to successfully persuade the CA that the CAA record does not exist by way of a fraudulent authoritative DNS server.

More significantly, ongoing enhancement of work in the CAA sphere will allow for CAs to get even more selective about issuance rules specified in CAA records. Let's Encrypt, for example, is currently contemplating a pull request for an enhancement to their handling of CAA records to allow the CAA records to further specify which of Let's Encrypt's challenge methods are acceptable for the domain holder, pursuant to the CAA records. (In other words, I can use CAA to indicate that only Let's Encrypt may issue AND FURTHERMORE that only the DNS-01 challenge is acceptable.) See: https://github.com/letsencrypt/boulder/pull/3003

The actual risk, then, is that the implementation of CAA checking WITHOUT DNSSEC validation enforcement for those sites for which DNSSEC has been enabled (and the right way to check is to get secure proof that the zone does not implement DNSSEC before deciding DNSSEC is not needed for a given FQDN) yield a much diminished value of the CAA mechanism, as it misses the opportunity for a cryptographically secure mechanism by which a domain holder can prevent issuance even in the face of a BGP IP space hijack of the authoritative DNS servers.

While I will concede that BGP hijacks of IP space for the purpose of fraudulent acquisition of DV certificates has to be a pretty rare case today, I assert that it is far easier to achieve than one might believe. Unfortunately, demonstrating how easily not just one who is well positioned to achieve this today can do so, but rather setting forth a template whereby one with modest means (corporately speaking) and starting from 0 technologically could do so is unfortunately too dangerous to ethically recommend. Nevertheless, it is the case that such a scenario could be undertaken pretty easily. I encourage those who doubt the same to reach out to a network engineer with significant IXP peering experience from among their own trusted professional associates for further discussion on the feasibility of these kinds of attacks.

In summary, my brief threat model in response is:

DNSSEC validation adds value in such scenarios as involve the existence of any publicly trusted CA known by said attacker to conduct a mechanism of automated domain validation via DNS queries AND such CA chosen as it executes these validation queries from a point of origin whose upstream routing may be manipulated via the attacker so as to intercept DNS query traffic intended to leave the CA destined for the authoritative DNS servers for the FDQN being attacked. In the absence of ubiquitious DNSSEC validation, even a properly DNSSEC signed zone is unlikely to evade an attack of this nature. In an environment where CAA checking is universally paired with proper DNSSEC validation of the CAA check queries, a properly DNSSEC signed zone will definitely shut down these attacks.

Thanks,

Matt Hardeman

[Matthew Hardeman]

Quite true. In the example scenario that I have just posted, such preference might well take the form of "Particular CA X is preferred as they don't perform DNSSEC validation of their CAA queries."