Re: CAA record checking issue

2019-05-13 Thread Matt Palmer via dev-security-policy
On Mon, May 13, 2019 at 01:35:09AM -0700, Mike Kushner via dev-security-policy 
wrote:
> On Monday, May 13, 2019 at 1:39:32 AM UTC+2, Matt Palmer wrote:
> > On Sat, May 11, 2019 at 08:37:53AM -0700, Han Yuwei via dev-security-policy 
> > wrote:
> > > This raised a question:
> > >  How can CA prove they have done CAA checks or not at the time of issue? 
> > 
> > They can't, just as they can't prove they have or haven't done
> > domain-control validation.  It's up to audits, external adversarial testing,
> > and the forthright honesty of CAs themselves to proactively report when they
> > have a problem, to identify when CAs have failed to maintain the necessary
> > standards.
> 
> Indeed.  It would have been awesome if CAA had included returning a signed
> token containing the result of the check, but that would probably have
> been impossible to roll out on all of the world's DNS servers.

Yep, at that point you've basically rolled out DNSSEC, and if you've managed
to achieve *that* Herculean feat, sites can just publish identity data in
DNS and you don't need CAs at all.

- Matt

-- 
Sure, it's possible to write C in an object-oriented way.  But, in practice,
getting an entire team to do that is like telling them to walk along a
straight line painted on the floor, with the lights off.
-- Tess Snider, slug-c...@slug.org.au

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


Re: CAA record checking issue

2019-05-13 Thread Mike Kushner via dev-security-policy
On Monday, May 13, 2019 at 1:39:32 AM UTC+2, Matt Palmer wrote:
> On Sat, May 11, 2019 at 08:37:53AM -0700, Han Yuwei via dev-security-policy 
> wrote:
> > This raised a question:
> >  How can CA prove they have done CAA checks or not at the time of issue? 
> 
> They can't, just as they can't prove they have or haven't done
> domain-control validation.  It's up to audits, external adversarial testing,
> and the forthright honesty of CAs themselves to proactively report when they
> have a problem, to identify when CAs have failed to maintain the necessary
> standards.
> 
> - Matt

Indeed. It would have been awesome if CAA had included returning a signed token 
containing the result of the check, but that would probably have been 
impossible to roll out on all of the world's DNS servers. 

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


Re: CAA record checking issue

2019-05-12 Thread Matt Palmer via dev-security-policy
On Sat, May 11, 2019 at 08:37:53AM -0700, Han Yuwei via dev-security-policy 
wrote:
> This raised a question:
>  How can CA prove they have done CAA checks or not at the time of issue? 

They can't, just as they can't prove they have or haven't done
domain-control validation.  It's up to audits, external adversarial testing,
and the forthright honesty of CAs themselves to proactively report when they
have a problem, to identify when CAs have failed to maintain the necessary
standards.

- Matt

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


Re: CAA record checking issue

2019-05-11 Thread Nick Lamb via dev-security-policy
On Fri, 10 May 2019 02:05:17 +
Jeremy Rowley via dev-security-policy
 wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1550645
> 
> Anyway, let me know what questions, comments, etc you have.

Thanks Jeremy,

If DigiCert is able to retrospectively achieve confidence that issuance
would have been permitted (because their records are good enough to go
back and see the CAA DNS records that were fetched but not used or at
the least the assessment made of those records at the time) I personally
think there is no need to revoke certificates that were in some sense
legitimately issued. To revoke them in these circumstances seems
perverse.

This also rewards keeping high quality issuance records that let you go
back and understand what went wrong. The BRs mandate some record
keeping, but we definitely don't always see evidence of good quality
record keeping in incident reports (I would count ISRG / Let's Encrypt
here definitely).


If DigiCert turns out not to have the records, or checking isn't done
for whatever reasons then I think all 1053 affected certs should be
revoked, without trying to justify narrowing it down further.

In the margins, e.g. if DigiCert can see that some cases have no CAA,
but in cases with CAA it's not possible to be sure if it would have
permitted issuance, I think we need to ask for all 1053 to be revoked
for consistency rather than making complicated decisions that have the
effect of penalizing some subscribers for doing the Right Thing.


I don't endorse the plan of revoking 16 certs based on CAA information
that's far (perhaps more than 12 months) newer than the issuance, I
don't think this is compatible with the declared philosophy of the CAA
and so it makes the message about what CAA is or is not for too
muddled. Revoking all 1053 makes more sense than revoking 16 on this
basis.


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


Re: CAA record checking issue

2019-05-11 Thread Han Yuwei via dev-security-policy
This raised a question:
 How can CA prove they have done CAA checks or not at the time of issue? 

在 2019年5月10日星期五 UTC+8上午10:05:36,Jeremy Rowley写道:
> FYI, we posted this today:
> 
>  
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1550645
> 
>  
> 
> Basically we discovered an issue with our CAA record checking system. If the
> system timed out, we would treat the failure as a DNS failure instead of an
> internal failure. Per the BRs Section 3.2.2:
> 
> "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"
> 
>  
> 
> The failure was not outside our infrastructure so issuance was improper. 
> 
>  
> 
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to revoke these certificates and reissue them (if they pass
> all the proper checks). The rest would pass if we issued today so we were
> going to leave these where they are while disclosing them to the Mozilla
> community. 
> 
>  
> 
> Other suggestions are welcome. 
> 
>  
> 
> The issue was put into the code back when CAA record checking became
> mandatory (Sept 2017).  We generally have a peer review of our code so that
> at least one other developer has looked at the system before release. In
> this case, neither PM nor a second reviewer was involved in the development.
> We've since implemented more stringent development processes, including
> ensuring a PM reviews and brings questions about projects to the compliance
> team. 
> 
>  
> 
> Anyway, let me know what questions, comments, etc you have.
> 
>  
> 
> Thanks!
> 
> Jeremy

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


RE: CAA record checking issue

2019-05-10 Thread Jeremy Rowley via dev-security-policy
The difference is we actually have the data at time of issuance. It just wasn’t 
correctly relied on for these specific certs. I think this means there is an 
open question on whether the issuance even was a mis-issuance since the CAA 
information was collected…even if it wasn’t perfect. 

 

This is why we’re revising the approach to say “Were the certs actually 
mis-issued? If yes, revoke. If no, then don’t revoke.”

 

I was looking at it like a law.  You may think you trespassed by walking on 
some grass. But if permission was granted at  the time to walk on the grass, 
then you never actually violated a rule (even if you didn’t know about the 
permission). If permission was granted later, you still broke that law and are 
accountable, even if no penalty is applied.  Here, we didn’t appropriately 
store the information but the data may have been stored and checked in a 
process. More succinctly said, the difference is the broken process may result 
in compliantly issued certificates which is different than a broken certs that 
are then remediated.  If I can prove the compliance at the time the cert was 
issued, then the certs shouldn’t be revoked. 

 

Does that makes sense? I can certainly revoke all 1100 if that’s the preferred 
approach, but I figure with a few days time I can better answer question of 
what were the results in a break of normally compliant process? 

 

Oh, one other factor is that the system wasn’t exploitable. The break was 
between two internal processes talking to each other so the errors couldn’t 
result in certificates issued to a bad actor.  It was also a very low volume 
compared to normal issue. Neither of these are good reasons or excuses. Instead 
they are the reason we thought we should perhaps not revoke all the certs until 
we better understand the compliance implications. 

 

From: Ryan Sleevi  
Sent: Friday, May 10, 2019 2:16 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA record checking issue

 

 

 

On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

The analysis was basically that all the verification documents are still good, 
which means if we issued the cert today, the issuance would pass without 
further checks (since the data itself is good for 825 days). Because of this, 
customers with domains that didn’t prohibit Digicert in their CAA record 
(anywhere in the chain) could simply reissue the certificate without a problem. 
We could require this of all customers. For the 16, issuance would fail if the 
CAA check was performed today. Therefore, we want to revoke those. 

 

The one reason I wanted more time to respond is that we think we may have most 
CAA records in our Splunk data for the time of issuance. Our new plan is that 
we will revoke all certs unless we can confirm the CAA record was permissive at 
the time of issuance. I don’t know the number of certs that we will revoke yet. 
I’ll post an update when we compare the Splunk data to the issuance data. 

 

Thanks for answering. I was hoping you had a more thorough analysis ;) I do 
have other questions about the implementation details, but I'll add those to 
the bug, so we can focus this discussion on the immediate remediation steps.

 

I guess my reservation with such an approach (and this is more a metapoint) is 
consider issuing an EV certificate without having the supporting documentation 
and/or without validating the documentation. You later come back to the 
documents, validate them, and find out you got lucky - the information was 
actually correct, even though the controls failed and the process wasn't 
followed. Do you revoke the certificates, on the basis the process failed, or 
do you not revoke them, because they were eventually consistent?

 

This might sound like a hypothetical, but it's a question this industry has 
faced in the past [1][2], and browsers have reached different conclusions than 
CAs. It's not immediately clear to me how the proposed response here differs 
from those past responses, and may highlight some of the difference in 
philosophies here. An analysis that considered these past events, and how they 
were received by the community, and how there may be different facts here that 
lead to different conclusions, would be useful in both validating and 
justifying the proposed course of action.

 

The real problem was the CA would kick off a request to the CAA checker. If the 
CA encountered an error, the request would time out. The CAA record may still 
have checked the CAA records appropriately but the CA never pulled the 
information to verify issuance authorization. So it’s a mis-issuance unless we 
can pull the data and prove it wasn’t. Combing through the archive data will 
take a while.

 

[1] 
https://wiki.mozilla.org/CA:Symantec_Issues#Issue_C:_Unauthorized_EV_Issuance_by_RAs_.28January_2014_-_February_2015.29
 

[2] 
https://wiki.mozil

Re: CAA record checking issue

2019-05-10 Thread Ryan Sleevi via dev-security-policy
On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley 
wrote:

> The analysis was basically that all the verification documents are still
> good, which means if we issued the cert today, the issuance would pass
> without further checks (since the data itself is good for 825 days).
> Because of this, customers with domains that didn’t prohibit Digicert in
> their CAA record (anywhere in the chain) could simply reissue the
> certificate without a problem. We could require this of all customers. For
> the 16, issuance would fail if the CAA check was performed today.
> Therefore, we want to revoke those.
>

>
> The one reason I wanted more time to respond is that we think we may have
> most CAA records in our Splunk data for the time of issuance. Our new plan
> is that we will revoke all certs unless we can confirm the CAA record was
> permissive at the time of issuance. I don’t know the number of certs that
> we will revoke yet. I’ll post an update when we compare the Splunk data to
> the issuance data.
>

Thanks for answering. I was hoping you had a more thorough analysis ;) I do
have other questions about the implementation details, but I'll add those
to the bug, so we can focus this discussion on the immediate remediation
steps.

I guess my reservation with such an approach (and this is more a metapoint)
is consider issuing an EV certificate without having the supporting
documentation and/or without validating the documentation. You later come
back to the documents, validate them, and find out you got lucky - the
information was actually correct, even though the controls failed and the
process wasn't followed. Do you revoke the certificates, on the basis the
process failed, or do you not revoke them, because they were eventually
consistent?

This might sound like a hypothetical, but it's a question this industry has
faced in the past [1][2], and browsers have reached different conclusions
than CAs. It's not immediately clear to me how the proposed response here
differs from those past responses, and may highlight some of the difference
in philosophies here. An analysis that considered these past events, and
how they were received by the community, and how there may be different
facts here that lead to different conclusions, would be useful in both
validating and justifying the proposed course of action.


> The real problem was the CA would kick off a request to the CAA checker.
> If the CA encountered an error, the request would time out. The CAA record
> may still have checked the CAA records appropriately but the CA never
> pulled the information to verify issuance authorization. So it’s a
> mis-issuance unless we can pull the data and prove it wasn’t. Combing
> through the archive data will take a while.
>

[1]
https://wiki.mozilla.org/CA:Symantec_Issues#Issue_C:_Unauthorized_EV_Issuance_by_RAs_.28January_2014_-_February_2015.29

[2]
https://wiki.mozilla.org/CA:Symantec_Issues#Issue_T:_CrossCert_Misissuances_.28January_2010_-_January_2017.29
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: CAA record checking issue

2019-05-10 Thread Jeremy Rowley via dev-security-policy
The analysis was basically that all the verification documents are still good, 
which means if we issued the cert today, the issuance would pass without 
further checks (since the data itself is good for 825 days). Because of this, 
customers with domains that didn’t prohibit Digicert in their CAA record 
(anywhere in the chain) could simply reissue the certificate without a problem. 
We could require this of all customers. For the 16, issuance would fail if the 
CAA check was performed today. Therefore, we want to revoke those.

 

The one reason I wanted more time to respond is that we think we may have most 
CAA records in our Splunk data for the time of issuance. Our new plan is that 
we will revoke all certs unless we can confirm the CAA record was permissive at 
the time of issuance. I don’t know the number of certs that we will revoke yet. 
I’ll post an update when we compare the Splunk data to the issuance data.  

 

The real problem was the CA would kick off a request to the CAA checker. If the 
CA encountered an error, the request would time out. The CAA record may still 
have checked the CAA records appropriately but the CA never pulled the 
information to verify issuance authorization. So it’s a mis-issuance unless we 
can pull the data and prove it wasn’t. Combing through the archive data will 
take a while.

 

Jeremy

 

From: Ryan Sleevi  
Sent: Friday, May 10, 2019 11:54 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA record checking issue

 

 

 

On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

We checked all the applicable CAA records and found 16 where the CAA record
would not permit us to issue if we were issuing a new cert today. What we
are proposing is to revoke these certificates and reissue them (if they pass
all the proper checks). The rest would pass if we issued today so we were
going to leave these where they are while disclosing them to the Mozilla
community. 

 

Could you share the risk analysis that helped you reach this latter conclusion?

 

That is, CAA is a time of check thing, and, as you note, you can't be sure they 
were appropriately authorized at the time of issuance. Thus, even if the site 
operator is a DigiCert customer now, or might have disabled CAA now, there's no 
ability to determine whether or not they previously approved it - or even 
whether the holder of that old certificate is still the authorized domain 
representative now (e.g. in the event of a domain transfer or sale)

 

In general, the default should be to revoke all. That said, if there's a 
thorough analysis that has considered this, and other scenarios, and that, on 
the whole, has led DigiCert to believe the current path is more appropriate, 
it'd be great if you could share that analysis. I think Tim's questions are 
useful as well, in understanding the reasoning.

 

Basically, without stating a position on whether your analysis is right or 
wrong, I'm hoping you can show your work in detail, and all the factors you 
considered. That sort of analysis is what helps the community build confidence 
that the chosen path, despite being a violation of the BRs, is a reflection of 
a CA thoughtfully considering all perspectives.



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 record checking issue

2019-05-10 Thread Jeremy Rowley via dev-security-policy
Hey Tim, 

The issue was a call between the CA and CAA checker. The CAA checker would 
check the DNS and verify the DNSSEC chain. However, when retrieving the 
information from the CAA checker, the CA had the error, which means the CAA 
check was not evaluated correctly. Under normal operation the CAA check does 
the DNSSEC , CAA, and other DNS queries. Here it wasn't a DNS failure - it was 
a communication failure between the CA and CAA checker. 

I guess you could say there were two failures in this case. First that the CAA 
check timed out internally and second that the DNSSEC check never happened. The 
mis-issuance still amounts to the same thing. 

Normally, even if we get a DNS failure, we can usually check to see if the zone 
is signed (at least at the root zone). If there is a signed root zone, then we 
treat the entire zone as signed (meaning we fail on error).  

Jeremy

-Original Message-
From: Tim Shirley  
Sent: Friday, May 10, 2019 7:30 AM
To: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA record checking issue

Jeremy,

Thanks for sharing this.  After reading your description, I'm curious how your 
system was previously (or is now) satisfying the third criteria needed to issue 
in the face of a record lookup failure: confirming that the domain's zone does 
not have a DNSSEC validation chain to the ICANN root.  Wouldn't any issuance 
require at least one successful DNS query in order to confirm the lack of a DS 
record somewhere between the TLD and the domain you're checking so you know the 
domain doesn't have a valid DNSSEC chain?  If the CAA checking service was 
down, wouldn't those have all timed out?  Or are those checks being done from a 
different system that wasn't down?

Regards,
Tim

On 5/9/19, 10:05 PM, "dev-security-policy on behalf of Jeremy Rowley via 
dev-security-policy"  wrote:

FYI, we posted this today:

 


https://scanmail.trustwave.com/?c=4062=99zU3MWO5ZnJnVq-TZZut0-4BjNGA3S27plK9QDITw=5=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid%3d1550645

 

Basically we discovered an issue with our CAA record checking system. If the
system timed out, we would treat the failure as a DNS failure instead of an
internal failure. Per the BRs Section 3.2.2:

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

 

The failure was not outside our infrastructure so issuance was improper. 

 

We checked all the applicable CAA records and found 16 where the CAA record
would not permit us to issue if we were issuing a new cert today. What we
are proposing is to revoke these certificates and reissue them (if they pass
all the proper checks). The rest would pass if we issued today so we were
going to leave these where they are while disclosing them to the Mozilla
community. 

 

Other suggestions are welcome. 

 

The issue was put into the code back when CAA record checking became
mandatory (Sept 2017).  We generally have a peer review of our code so that
at least one other developer has looked at the system before release. In
this case, neither PM nor a second reviewer was involved in the development.
We've since implemented more stringent development processes, including
ensuring a PM reviews and brings questions about projects to the compliance
team. 

 

Anyway, let me know what questions, comments, etc you have.

 

Thanks!

Jeremy





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 record checking issue

2019-05-10 Thread Jeremy Rowley via dev-security-policy
Okay. I'm working on something and will post it soon.

From: Ryan Sleevi 
Sent: Friday, May 10, 2019 11:54:14 AM
To: Jeremy Rowley
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA record checking issue



On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
We checked all the applicable CAA records and found 16 where the CAA record
would not permit us to issue if we were issuing a new cert today. What we
are proposing is to revoke these certificates and reissue them (if they pass
all the proper checks). The rest would pass if we issued today so we were
going to leave these where they are while disclosing them to the Mozilla
community.

Could you share the risk analysis that helped you reach this latter conclusion?

That is, CAA is a time of check thing, and, as you note, you can't be sure they 
were appropriately authorized at the time of issuance. Thus, even if the site 
operator is a DigiCert customer now, or might have disabled CAA now, there's no 
ability to determine whether or not they previously approved it - or even 
whether the holder of that old certificate is still the authorized domain 
representative now (e.g. in the event of a domain transfer or sale)

In general, the default should be to revoke all. That said, if there's a 
thorough analysis that has considered this, and other scenarios, and that, on 
the whole, has led DigiCert to believe the current path is more appropriate, 
it'd be great if you could share that analysis. I think Tim's questions are 
useful as well, in understanding the reasoning.

Basically, without stating a position on whether your analysis is right or 
wrong, I'm hoping you can show your work in detail, and all the factors you 
considered. That sort of analysis is what helps the community build confidence 
that the chosen path, despite being a violation of the BRs, is a reflection of 
a CA thoughtfully considering all perspectives.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: CAA record checking issue

2019-05-10 Thread Ryan Sleevi via dev-security-policy
On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to revoke these certificates and reissue them (if they
> pass
> all the proper checks). The rest would pass if we issued today so we were
> going to leave these where they are while disclosing them to the Mozilla
> community.
>

Could you share the risk analysis that helped you reach this latter
conclusion?

That is, CAA is a time of check thing, and, as you note, you can't be sure
they were appropriately authorized at the time of issuance. Thus, even if
the site operator is a DigiCert customer now, or might have disabled CAA
now, there's no ability to determine whether or not they previously
approved it - or even whether the holder of that old certificate is still
the authorized domain representative now (e.g. in the event of a domain
transfer or sale)

In general, the default should be to revoke all. That said, if there's a
thorough analysis that has considered this, and other scenarios, and that,
on the whole, has led DigiCert to believe the current path is more
appropriate, it'd be great if you could share that analysis. I think Tim's
questions are useful as well, in understanding the reasoning.

Basically, without stating a position on whether your analysis is right or
wrong, I'm hoping you can show your work in detail, and all the factors you
considered. That sort of analysis is what helps the community build
confidence that the chosen path, despite being a violation of the BRs, is a
reflection of a CA thoughtfully considering all perspectives.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: CAA record checking issue

2019-05-10 Thread Tim Shirley via dev-security-policy
Jeremy,

Thanks for sharing this.  After reading your description, I'm curious how your 
system was previously (or is now) satisfying the third criteria needed to issue 
in the face of a record lookup failure: confirming that the domain's zone does 
not have a DNSSEC validation chain to the ICANN root.  Wouldn't any issuance 
require at least one successful DNS query in order to confirm the lack of a DS 
record somewhere between the TLD and the domain you're checking so you know the 
domain doesn't have a valid DNSSEC chain?  If the CAA checking service was 
down, wouldn't those have all timed out?  Or are those checks being done from a 
different system that wasn't down?

Regards,
Tim

On 5/9/19, 10:05 PM, "dev-security-policy on behalf of Jeremy Rowley via 
dev-security-policy"  wrote:

FYI, we posted this today:

 


https://scanmail.trustwave.com/?c=4062=99zU3MWO5ZnJnVq-TZZut0-4BjNGA3S27plK9QDITw=5=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid%3d1550645

 

Basically we discovered an issue with our CAA record checking system. If the
system timed out, we would treat the failure as a DNS failure instead of an
internal failure. Per the BRs Section 3.2.2:

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

 

The failure was not outside our infrastructure so issuance was improper. 

 

We checked all the applicable CAA records and found 16 where the CAA record
would not permit us to issue if we were issuing a new cert today. What we
are proposing is to revoke these certificates and reissue them (if they pass
all the proper checks). The rest would pass if we issued today so we were
going to leave these where they are while disclosing them to the Mozilla
community. 

 

Other suggestions are welcome. 

 

The issue was put into the code back when CAA record checking became
mandatory (Sept 2017).  We generally have a peer review of our code so that
at least one other developer has looked at the system before release. In
this case, neither PM nor a second reviewer was involved in the development.
We've since implemented more stringent development processes, including
ensuring a PM reviews and brings questions about projects to the compliance
team. 

 

Anyway, let me know what questions, comments, etc you have.

 

Thanks!

Jeremy



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


CAA record checking issue

2019-05-09 Thread Jeremy Rowley via dev-security-policy
FYI, we posted this today:

 

https://bugzilla.mozilla.org/show_bug.cgi?id=1550645

 

Basically we discovered an issue with our CAA record checking system. If the
system timed out, we would treat the failure as a DNS failure instead of an
internal failure. Per the BRs Section 3.2.2:

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

 

The failure was not outside our infrastructure so issuance was improper. 

 

We checked all the applicable CAA records and found 16 where the CAA record
would not permit us to issue if we were issuing a new cert today. What we
are proposing is to revoke these certificates and reissue them (if they pass
all the proper checks). The rest would pass if we issued today so we were
going to leave these where they are while disclosing them to the Mozilla
community. 

 

Other suggestions are welcome. 

 

The issue was put into the code back when CAA record checking became
mandatory (Sept 2017).  We generally have a peer review of our code so that
at least one other developer has looked at the system before release. In
this case, neither PM nor a second reviewer was involved in the development.
We've since implemented more stringent development processes, including
ensuring a PM reviews and brings questions about projects to the compliance
team. 

 

Anyway, let me know what questions, comments, etc you have.

 

Thanks!

Jeremy



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