Re: [cabfpub] Two CAA questions

[Phillip via Public]

One of the main things that CAs do as part of their business is precisely 
helping the customer configure their server to use the product. This is only 
one of dozens of misconfiguration issues that arise.

 

DNSSEC is complex enough in itself. One of the side effects of DNSSEC is that 
it will make any and all misconfigurations in your existing DNS apparent. It is 
the DNS equivalent of a ‘lights out’ data center. This is one of the reasons 
why positioning DANE to compete with the WebPKI was an own goal. The parties 
that might have assisted in the deployment of DNSSEC and helped customers work 
through the deployment were intentionally locked out.

 

So where the CABForum documents say ‘must not issue’, what this actually means 
in practice is ‘must not issue until the CA has helped the customer get their 
act in gear’. 

 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Friday, August 18, 2017 10:02 AM
To: Gervase Markham <g...@mozilla.org>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>
Cc: phill...@comodo.com; Kirk Hall <kirk.h...@entrustdatacard.com>
Subject: Re: [cabfpub] Two CAA questions

 

 

 

On Fri, Aug 18, 2017 at 7:25 AM, Gervase Markham via Public 
<public@cabforum.org <mailto:public@cabforum.org> > wrote:

Is anyone able to explain why this scenario is at all common? Why would
the authoritative nameservers for a domain refuse to answer queries, if
the owner of the domain wanted the domain to work at all?

 

Isn't that two questions? That is, can someone explain this scenario, and how 
common is it? :)

 

I think https://github.com/dns-violations/dns-violations is a useful collection 
of various ways that vendors have improperly implemented DNS and could result 
in affecting (a limited number of sites, customers of a particular DNS host / 
CDN).

 

I'm not aware of any publicly available data showing prevalence or that it is 
common, especially in the context of CA issuance, and so I would think it would 
be a wonderful contribution to the Internet community if CAs are seeing such 
issues, that they could publish information about it.

 

I know Let's Encrypt has investigated some issues, such as 
https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748 
and https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802 , 
but these are indicative of gross server misconfigurations, and so failing to 
issue a certificate is a correct response for a misconfiguration that is 
indistinguishable from an attack.

 

As CAs often remark about OCSP, the most secure solution is to fail closed when 
a service fails. Given that CAs have direct lines with the customers affected 
by such service failures - and thus, the means to remedy the issue - this does 
not seem at all an onerous request.

 

As you said, and as Phillip mentioned, this is working as intended and 
designed, and important for security, so if there is more data that can be 
shared to help understand these concerns, that'd be useful, but otherwise it 
doesn't seem necessary to change anything.

 

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Two CAA questions

[Ryan Sleevi via Public]

On Fri, Aug 18, 2017 at 7:25 AM, Gervase Markham via Public <
public@cabforum.org> wrote:

> Is anyone able to explain why this scenario is at all common? Why would
> the authoritative nameservers for a domain refuse to answer queries, if
> the owner of the domain wanted the domain to work at all?
>

Isn't that two questions? That is, can someone explain this scenario, and
how common is it? :)

I think https://github.com/dns-violations/dns-violations is a useful
collection of various ways that vendors have improperly implemented DNS and
could result in affecting (a limited number of sites, customers of a
particular DNS host / CDN).

I'm not aware of any publicly available data showing prevalence or that it
is common, especially in the context of CA issuance, and so I would think
it would be a wonderful contribution to the Internet community if CAs are
seeing such issues, that they could publish information about it.

I know Let's Encrypt has investigated some issues, such as
https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748
and https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802
, but these are indicative of gross server misconfigurations, and so
failing to issue a certificate is a correct response for a misconfiguration
that is indistinguishable from an attack.

As CAs often remark about OCSP, the most secure solution is to fail closed
when a service fails. Given that CAs have direct lines with the customers
affected by such service failures - and thus, the means to remedy the issue
- this does not seem at all an onerous request.

As you said, and as Phillip mentioned, this is working as intended and
designed, and important for security, so if there is more data that can be
shared to help understand these concerns, that'd be useful, but otherwise
it doesn't seem necessary to change anything.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Two CAA questions

[Gervase Markham via Public]

On 02/08/17 23:40, philliph--- via Public wrote:
>> We cannot, however, determine whether the "domain’s zone does not have
>> a DNSSEC validation chain to the ICANN root" because the domain's zone
>> authoritative name servers are refusing to answer our DNS queries.
>>  
>> This scenario is encountered often enough in the real world that it
>> would prevent many certificates from being issued if ballot 187 is
>> followed.

Is anyone able to explain why this scenario is at all common? Why would
the authoritative nameservers for a domain refuse to answer queries, if
the owner of the domain wanted the domain to work at all?

>> One potential solution is to allow CA's to treat REFUSED status
>> responses from authoritative name servers as permission to issue.
> 
> ​The problem with doing this is that it opens up a downgrade attack.

As PHB says, this doesn't sound like the right route.

> We know if the zone is DNSSEC signed or not (NSEC3 in the parent zone).
> REFUSED + DNSSEC should mean no certificate. ​If you turn on DNSSEC and
> much it up, then you are going to be in for a world of hurt anyways.
> That is what DNSSEC is for.

So you can determine whether the parent zone is DNSSEC-signed or not
without needing a response from the authoritative nameserver for the
domain itself? Do I have this right: if the parent zone is not signed,
clearly the domain itself won't be signed. But if the parent zone it
signed, you can't tell if the domain itself is signed or not without the
authoritative nameserver telling you.

Is that right?

Oh, and yes, an empty record means "no-one can issue".

Gerv


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Two CAA questions

[Gervase Markham via Public]

On 02/08/17 23:40, philliph--- via Public wrote:
>> We cannot, however, determine whether the "domain’s zone does not have
>> a DNSSEC validation chain to the ICANN root" because the domain's zone
>> authoritative name servers are refusing to answer our DNS queries.
>>  
>> This scenario is encountered often enough in the real world that it
>> would prevent many certificates from being issued if ballot 187 is
>> followed.

Is anyone able to explain why this scenario is at all common? Why would
the authoritative nameservers for a domain refuse to answer queries, if
the owner of the domain wanted the domain to work at all?

>> One potential solution is to allow CA's to treat REFUSED status
>> responses from authoritative name servers as permission to issue.
> 
> ​The problem with doing this is that it opens up a downgrade attack.

As PHB says, this doesn't sound like the right route.

> We know if the zone is DNSSEC signed or not (NSEC3 in the parent zone).
> REFUSED + DNSSEC should mean no certificate. ​If you turn on DNSSEC and
> much it up, then you are going to be in for a world of hurt anyways.
> That is what DNSSEC is for.

So you can determine whether the parent zone is DNSSEC-signed or not
without needing a response from the authoritative nameserver for the
domain itself? Do I have this right: if the parent zone is not signed,
clearly the domain itself won't be signed. But if the parent zone it
signed, you can't tell if the domain itself is signed or not without the
authoritative nameserver telling you.

Is that right?

Oh, and yes, an empty record means "no-one can issue".

Gerv


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Two CAA questions

[philliph--- via Public]

> On Aug 2, 2017, at 6:23 PM, Kirk Hall via Public  wrote:
> 
> I have two CAA questions from our technical group.  I am posting here to see 
> what others think.  Do we need to make any changes to BR 3.2.2.8 (created 
> under Ballot 187)?  Thanks for any feedback.
>  
> QUESTION 1
>  
> Subject: CAA ballot and handling of REFUSED status response from 
> authoritative name servers
>  
> Suppose we have a domain "demo-k2k.com " that have NS 
> records pointing to "ns1.demo-k2k.com " and 
> ns2.demo-k2k.com  as the authoritative name 
> servers. When we query "ns1.demo-k2k.com " for the 
> CAA records for "demo-k2k.com ", it returns a status of 
> REFUSED. This may be due to a misconfiguration or the restricted access may 
> be intentional.
>  
> We now have a scenario where the record lookup for "demo-k2k.com 
> " has failed.
>  
> According to ballot 187, CAs are permitted to treat a record lookup failure 
> as permission to issue if:
>  
> 1.   the failure is outside the CA’s infrastructure;
> 2.   the lookup has been retried at least once; and
> 3.   the domain’s zone does not have a DNSSEC validation chain to the 
> ICANN root.
>  
> Condition #1 is satisfied, the failure is outside the CA’s infrastructure.
> We can satisfy Condition #2 by retrying – we get the same REFUSED status in 
> the response.
>  
> Because of the "and" clause in above ballot excerpt, we must also satisfy 
> condition #3 if we want to treat the lookup failure as permission to issue.
> We cannot, however, determine whether the "domain’s zone does not have a 
> DNSSEC validation chain to the ICANN root" because the domain's zone 
> authoritative name servers are refusing to answer our DNS queries.
>  
> This scenario is encountered often enough in the real world that it would 
> prevent many certificates from being issued if ballot 187 is followed.
>  
> One potential solution is to allow CA's to treat REFUSED status responses 
> from authoritative name servers as permission to issue.

​The problem with doing this is that it opens up a downgrade attack.

We know if the zone is DNSSEC signed or not (NSEC3 in the parent zone). REFUSED 
+ DNSSEC should mean no certificate. ​If you turn on DNSSEC and much it up, 
then you are going to be in for a world of hurt anyways. That is what DNSSEC is 
for.


> QUESTION 2
>  
> Subject: Handling CAA record with single character in it
>  
> We have found a CAA record that consists only of a semi-colon “;”  So the 
> field is not empty, but also does not designate any known CAs.
>  
> Our team assumes this effectively blocks all CAs from issuing to this domain. 
>  Do others agree?
> 

Yes. The original intention was that a completely empty record should prevent 
issue. That may well be harder to enter in the config file of course. 

There are many domains that are bought and simply parked. They are not in use 
so why would someone be getting a certificate for them?___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Two CAA questions

[Kirk Hall via Public]

I have two CAA questions from our technical group.  I am posting here to see 
what others think.  Do we need to make any changes to BR 3.2.2.8 (created under 
Ballot 187)?  Thanks for any feedback.

QUESTION 1

Subject: CAA ballot and handling of REFUSED status response from authoritative 
name servers

Suppose we have a domain "demo-k2k.com" that have NS records pointing to 
"ns1.demo-k2k.com" and ns2.demo-k2k.com as the authoritative name servers. When 
we query "ns1.demo-k2k.com" for the CAA records for "demo-k2k.com", it returns 
a status of REFUSED. This may be due to a misconfiguration or the restricted 
access may be intentional.

We now have a scenario where the record lookup for "demo-k2k.com" has failed.

According to ballot 187, CAs are permitted to treat a record lookup failure as 
permission to issue if:


1.   the failure is outside the CA's infrastructure;

2.   the lookup has been retried at least once; and

3.   the domain's zone does not have a DNSSEC validation chain to the ICANN 
root.

Condition #1 is satisfied, the failure is outside the CA's infrastructure.
We can satisfy Condition #2 by retrying - we get the same REFUSED status in the 
response.

Because of the "and" clause in above ballot excerpt, we must also satisfy 
condition #3 if we want to treat the lookup failure as permission to issue.
We cannot, however, determine whether the "domain's zone does not have a DNSSEC 
validation chain to the ICANN root" because the domain's zone authoritative 
name servers are refusing to answer our DNS queries.

This scenario is encountered often enough in the real world that it would 
prevent many certificates from being issued if ballot 187 is followed.

One potential solution is to allow CA's to treat REFUSED status responses from 
authoritative name servers as permission to issue.

QUESTION 2

Subject: Handling CAA record with single character in it

We have found a CAA record that consists only of a semi-colon ";"  So the field 
is not empty, but also does not designate any known CAs.

Our team assumes this effectively blocks all CAs from issuing to this domain.  
Do others agree?

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public