Re: CAA Certificate Problem Report

[Matthew Hardeman via dev-security-policy]

On Tuesday, September 19, 2017 at 10:37:20 AM UTC-5, Gervase Markham wrote:
> On 19/09/17 14:58, Nick Lamb wrote:
> > An attacker only has to _prefer_ one particular CA for any reason,
> 
> 
> Yep, fair.
> 
> Gerv

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."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

Hi Nick,

On 13/09/17 20:39, Nick Lamb wrote:
> 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?

There seems to have been some progress made on the CAB Forum list in
terms of defining exactly what it means for a domain to have or not have
DNSSEC, and how a CA can determine that.

It might also be worth thinking about the value that DNSSEC adds, over
and above a non-secure CAA check, in various attack scenarios. At the
moment, I'm thinking that DNSSEC doesn't necessarily add much. Here are
3 quick scenarios, for a domain which is CAA locked so only CA Bar can
issue:

* Misguided employee tries to get CA Foo to issue for your domain - in
which case, non-DNSSEC-signed checking will do.

* Attacker has some control of CA Foo but can't override CAA check - in
which case, non-DNSSEC-signed checking will do.

* Attacker has control of CA Foo but can override CAA check - in which
case, it doesn't matter what your DNS says.

Gerv

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

Re: CAA Certificate Problem Report

[Jakob Bohm via dev-security-policy]

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, , 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

Re: CAA Certificate Problem Report

[Matthew Hardeman via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Nick Lamb via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Adriano Santoni via dev-security-policy]

+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:jonat...@titanous.com]
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report



On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
<dev-security-policy@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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy




smime.p7s
Description: Firma crittografica S/MIME
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Nick Lamb via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> 
>>> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@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

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

Re: CAA Certificate Problem Report

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
> dev-security-policy@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?

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.


I'm not sure I would agreee with that, because it is completely
unmeasurable, and every CA being "compliant" with such a requirement would
still have resulted in the same outcome.

>
> 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 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?

>
> > 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?

This feels very knee-jerk, but I may be misunderstanding part of your
argument. Perhaps you could do a small write-up of why you feel things are
problematic, since the original argument - which seems to be "some CAs had
trouble" - is not at all compelling given the facts and the years of
discussion that lead up to this ballot.

>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy 
>  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

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:r...@sleevi.com] 
Sent: Monday, September 11, 2017 3:42 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; Jonathan Rudenberg 
<jonat...@titanous.com>
Cc: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

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

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


> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
> <dev-security-policy@lists.mozilla.org 
> <mailto:dev-security-policy@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Ryan Sleevi via dev-security-policy]

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-security-policy@lists.mozilla.org> wrote:

> I would support that.  I can't recall why it's in there.
>
> -Original Message-
> From: Jonathan Rudenberg [mailto:jonat...@titanous.com]
> Sent: Monday, September 11, 2017 3:19 PM
> To: Jeremy Rowley <jeremy.row...@digicert.com>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: CAA Certificate Problem Report
>
>
> > On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy <
> dev-security-policy@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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

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

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


> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
> <dev-security-policy@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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
>  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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

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=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, September 11, 2017 2:56 PM
To: Nick Lamb <tialara...@gmail.com>; 
mozilla-dev-security-pol...@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=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

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=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Nick Lamb via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

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:a...@andrewayer.name] 
Sent: Saturday, September 9, 2017 1:01 PM
To: Jonathan Rudenberg <jonat...@titanous.com>
Cc: Jonathan Rudenberg via dev-security-policy 
<dev-security-policy@lists.mozilla.org>; Peter Bowen <pzbo...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley 
<jeremy.row...@digicert.com>
Subject: Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 06:57:39 -0400
Jonathan Rudenberg via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:

> 
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy 
> > <dev-security-policy@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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

On 09/09/17 10:21, Jeremy Rowley wrote:
> Certificate 1 contains a single DNS identifier for
> 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  . IN
> CAA 0 issue "caatestsuite.com  "
> 
> Therefore, only 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

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

Re: CAA Certificate Problem Report

[Andrew Ayer via dev-security-policy]

On Sat, 9 Sep 2017 18:10:02 -0700
Peter Bowen  wrote:

> On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer 
> wrote:
> > On Sat, 9 Sep 2017 13:53:52 -0700
> > Peter Bowen via dev-security-policy
> >  wrote:
> >
> >> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer 
> >> 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.
> 
> 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)

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Peter Bowen via dev-security-policy]

On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer  wrote:
> On Sat, 9 Sep 2017 13:53:52 -0700
> Peter Bowen via dev-security-policy
>  wrote:
>
>> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer 
>> 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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Andrew Ayer via dev-security-policy]

On Sat, 9 Sep 2017 13:53:52 -0700
Peter Bowen via dev-security-policy
 wrote:

> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer 
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Peter Bowen via dev-security-policy]

On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer  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 unbound-b...@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 :
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 : 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)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Peter Bowen via dev-security-policy]

On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer  wrote:
> On Sat, 9 Sep 2017 08:49:01 -0700
> Peter Bowen via dev-security-policy
>  wrote:
>
>> On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg
>>  wrote:
>> >
>> >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
>> >>  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.

RFC 4033 refers to 4035 for the details on the protocol.  In RFC 4035

Re: CAA Certificate Problem Report

[Andrew Ayer via dev-security-policy]

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

> 
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
> >  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Peter Bowen via dev-security-policy]

On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg
 wrote:
>
>> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy 
>>  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.

As a big of background, in order to be properly signed, the zone must
have unexpired signatures over at least the SOA record (as this is the
minimal allowed signature when using NSEC3 with Opt-Out).
Additionally this case never exists with zones signed using NSEC or
NSEC3 without opt-out, as they will provide a either a denial of
existence or a signature that disclaims CAA record type existence.

So this bullet in the BRs only triggers when:
- SOA record has a valid signature
- There is a DNSKEY for the zone that matches the DS record in the parent zone
- The DS record in the parent zone is signed
- The above three are true for all zones back to the root zone
- The request for a CAA record for the QNAME returns an error
- The request for DNSSEC information for the QNAME succeeds
- The DNSSEC information does not provide information on the name
(e.g. is for records before and after but the opt-out flag is set)

In all of these are present, the CA may not issue.  If the DNSSEC
information is valid and says there is a CAA record in the type
bitmaps but the server returned an error for CAA records, then the CA
must not issue.

I don't think your tests cover either of these cases.  I think any
other case allows issuance as it follows the path of no CAA record.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy 
>  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

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 
>  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=CAA=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=CAA=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/

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

Re: CAA Certificate Problem Report

[Peter Bowen via dev-security-policy]

> 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  .
> 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 
> .  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy