Re: DarkMatter Concerns
G’day Folks, It was a pleasure meeting many of the Mozilla community face to face at the CAB Forum meeting at Apple HQ last week. There are many others of you however, whose interface to the community is right here on this list, and so I wanted to share my perspective and feedback here on the recent dialogue so that the openness and transparency of the community is preserved. Over the past few weeks, there’s been much debate and shared points of view around DarkMatter’s multi-year process to have our CA Roots included in Mozilla’s Root Store. Who could have predicted that along the way, the community would have such wide-spread impact from the serialNumber entropy issue? I do think the BRs are a little ambiguously worded in this regards, and this is what certainly tripped us up, but upon learning what was intended by the standard, DarkMatter has completed its revocation of every still valid affected TLS certificate (~175), and we actioned that immediately, completing the process over about 72 hrs (timing over the week-end in the UAE was not optimal for us otherwise we could have completed it sooner). We still need to re-issue the Issuing CAs and submitted Roots – these are dependent on the availability of our WebTrust Auditors, but we expect this to be finalized in the next week or so. Many others in the community are also evaluating replacement of affected certificates e.g. see [1] [2] [3], etc. But the volumes these organizations are dealing with will make it difficult to meet BR revocation timelines, which is why I think Mozilla’s recent acknowledgement of this challenge with a proposal for an updated best practice for revocation is the right discussion to have. I think this is where the community is at its best: working together to identify and manage issues, learning from each other in how best to take action and resolving it as quickly as possible while maintaining the security and integrity of services for end users. After all, we ultimately share the same goal: transparent community-based processes that promote participation, accountability and trust [4]. Resolving this issue together is a good example of this principle in action. As I reflect on the many discussions in this community, and also with the 40-odd companies at last week’s CA/B Forum, it is clear that there is quite an interest in the DarkMatter story. Unfortunately, the one that has often been promoted as evidence in this community – is one that is not based on truth, and one that has consistently been refuted by DarkMatter. I would like to set the record straight once and for all, and share with all of you why DarkMatter’s story is not what some have claimed, but is, I believe, actually completely aligned with Mozilla’s own manifesto. DarkMatter Group was founded by Faisal Al Bannai, one of the most accomplished business leaders in the Middle East [5], as a commercial business entity that specializes in Cyber Security services, and solutions. Al Bannai served as CEO and founder until recently (2018), when he handed over the leadership role of the company to Karim Sabbagh, formerly the CEO of the world leading satellite fleet operator SES [6]. Al Bannai is the sole beneficial shareholder of the DarkMatter Group. The CA business that I head within the DarkMatter Group, and which I will provide further details below, is a completely independent business unit housed in a legally separate subsidiary company. The general business of the DarkMatter Group is all centered around cybersecurity. DarkMatter is very active in our local constituency [7], [8], [9], we have even developed and launched our own mobile phone [10]. The Cybersecurity divisions of DarkMatter are fully engaged in and participate in identifying and disclosing malicious applications that attack the security and privacy of individuals everywhere. Some recent examples of this are where DarkMatter researchers identified and informed Google of a malicious application available on the Google play store [11], and DarkMatter researchers also made a responsible disclosure to Apple of a significant attack that “bypasses all native macOS security measures”, (which findings were also presented at Hack-In-the-Box conference in Singapore [12]. This just highlights a couple. For those who have questioned who is really in the driving seat of the DarkMatter CAs, I want to assure you that DarkMatter’s PKI business has always been operated independently. We are a legally separate entity – housed under a subsidiary of the DarkMatter Group. Only myself and my handpicked team ever have hands on key material, and no single individual can effect an issuance without the validation of a counterpart and always under multiparty and multifactor authentication. We have stringent controls around who is eligible to hold a trusted role, and they must continue to meet operational KPIs, training and risk evaluation metrics to remai
Re: CFCA certificate with invalid domain
On 18/03/2019 02:05, Nick Lamb wrote: On Fri, 15 Mar 2019 19:41:58 -0400 Jonathan Rudenberg via dev-security-policy wrote: I've noted this on a similar bug and asked for details: https://bugzilla.mozilla.org/show_bug.cgi?id=1524733 I can't say that this pattern gives me any confidence that the CA (CFCA) does CAA checks which are required by the BRs. I mean, how do you do a CAA check for a name that can't even exist? If you had the technology to run this check, and one possible outcome is "name can't even exist" why would you choose to respond to that by issuing anyway, rather than immediately halting issuance because something clearly went badly wrong? So I end up thinking probably CFCA does not actually check names with CAA before issuing, at least it does not check the names actually issued. Technically, the name can exist, if (for some bad reason) ICANN were to create the con. TLD (which would be a major invitation to phishing). As "not found" is a permissive CAA check result, CAA checking may be perfectly fine in this case. Domain control validation however obviously failed, as no one controls the non-existent domain, and thus no one could have proven control of that domain. 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: Survey of (potentially noncompliant) Serial Number Lengths
On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote: > On 18/03/2019 17:05, Kurt Roeckx wrote: >> On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via >> dev-security-policy wrote: >>> >>> When a value in column E is 100%, this is pretty solid evidence of >>> noncompliance with BR 7.1. >>> When the values in column E and G are both approximately 50%, this >>> suggests (but does not prove) that the CA is handling the output from >>> their CSPRNG correctly. >> >> Sould F/G say >= 64, instead of > 64? > > Yes. Fixed. Thanks! Perhaps it would make sense to separate out <64, ==64, >64? 100% "64-bit" serial numbers would indicate an algorithm using 63 bits of entropy and the top bit coerced to 1. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updated Revocation Best Practices
On Sat, Mar 16, 2019 at 12:49 PM Wayne Thayer wrote:
> Ryan - Thank you for the feedback.
>
> On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi wrote:
>
>> While I realize the thinking is with regards to the recent serial number
>> issue, a few questions emerge:
>>
>> 1) Based on the software vendor reporting, they don’t view this as a
>> software defect, but a CA misconfiguration. Do you believe the current
>> policy, as worded, addresses that ambiguity?
>>
>>
> As the language is an example, I don't believe it needs to address this
> distinction. I intended "defect" to mean a defect in the certificate, so
> perhaps it would help to specify that - i.e. "certificate defect"?
>
I guess the challenge is it introduces the ontology that some folks have
advocated, but no one actually knows where the lines should be drawn, as
every example has had flaws. That is, a "certificate defect" could be
everything from granting basicConstraints:CA=true (e.g. as we saw with
Turktrust [1]) due to a misconfigured certificate profile (which, like
this, was an "off by one" error) to something like misencoded sequences [2].
My biggest worry with the proposal is that it seems to actually favor not
revoking/responding to systemic issues (those which can affect a
significant portion of the CA's issued certificates), whereas I think the
intent is that non-revocation should be exceptional and that the CA should
be moving to systemically address things.
I think the end-goal, for both cases, remains the same: that the CA take
holistic steps to make revocation easier and painless, whether they're
dealing with systemic issues (such as serial numbers or validation methods)
or exceptional situations (such as a rogue RA or validation agent). Looking
at Heartbleed as the example, we know that a massive number of Subscribers
and certificates were affected - it seems like this example would have
encouraged non-revocation, by choosing the size of impact as the
illustrative example.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=825022
[2]
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
> 4) This new policy seems to explicitly allow a CA never revoking a
>> non-compliant Certificate. Is that your intent? If so, is there any concern
>> that this introduces the risk of CAs presenting revocation as being
>> “required by Mozilla” as opposed to the factually correct and accurate
>> “required by the Baseline Requirements” if Mozilla or this community should
>> disagree with such a decision?
>>
>>
> Is there any difference between delaying revocation until a certificate
> expires and not revoking at all? Is there any difference between CAs
> misrepresenting revocation as "being required by Mozilla to happen by X
> date" and "being required by Mozilla"?
>
Fair points. I think the previous policy encouraged a more concrete plan of
action ("when"), and did not leave the CA decision making capability ("if")
which could create a conflict between the CA's decisions and the community
expectations. That said, you make a good point - if their "when" is "when
the certificate expires", then it's implicitly an "if" as well, and that
remains unless/until "when" is more prescreptive.
> 5) If multiple CAs are affected by a common incident, this seems to
>> encourage delaying revocation as long as possible. It’s unclear whether a
>> CA that can and does revoke their certificates will be more or less
>> favorably considered, both by the ecosystem and by this community. Given
>> the economic incentives, it seems to strongly discourage revocation, as a
>> way of competitive differentiation.
>>
>>
> I'm not following how these changes have the effect of encouraging
> multiple CAs to delay revocation as long as possible. but I do think it
> would be useful to state that CAs who violate the BRs will always be looked
> upon less favorably than those who do not.
>
If a given CA is faced with a systemic issue - such as serial numbers -
then they have a decision whether to replace a majority of certificates or
not. Independent of any analysis, there will naturally be a preference to
not revoke "if we don't have to". Because the encouragement to post on the
Forum, and because these discussions show that people's opinions about the
seriousness/reasonableness of the matter is, in some way, impacted by how
many other CAs are impacted, there's a natural incentive to delay
revocation as much as possible (and to draw out discussions as much as
possible), in the hopes that a decision to not revoke will end up being
more favorable. If the determination is that revocation is not necessary,
the CAs that reported and revoked effectively went through more "pain" that
was needed.
I think this ties back up to the first remarks, about understanding what
CAs are systemically doing to prevent further issues. I would think that
the end goal is that, regardless of severity, CAs should be moving to
systems where it's easier to mass-revoke. If large CA
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 17:05, Kurt Roeckx wrote: > On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via > dev-security-policy wrote: >> >> When a value in column E is 100%, this is pretty solid evidence of >> noncompliance with BR 7.1. >> When the values in column E and G are both approximately 50%, this >> suggests (but does not prove) that the CA is handling the output from >> their CSPRNG correctly. > > Sould F/G say >= 64, instead of > 64? Yes. Fixed. Thanks! -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via dev-security-policy wrote: > > When a value in column E is 100%, this is pretty solid evidence of > noncompliance with BR 7.1. > When the values in column E and G are both approximately 50%, this > suggests (but does not prove) that the CA is handling the output from > their CSPRNG correctly. Sould F/G say >= 64, instead of > 64? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 15:43, Rob Stradling via dev-security-policy wrote: > On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote: > >> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: >>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: >> If any other CA wants to check theirs before someone else does, then now is surely the time to speak up. >>> >>> Someone else is in the process of checking... ;-) >> >> The purpose of this survey is to flush out any further CAs that are (or >> have been) noncompliant with BR 7.1 but have not yet disclosed an >> incident. The report now also includes issuing CAs whose certificates have not been disclosed to the CCADB, which of course is permitted for technically-constrained intermediates. (Many thanks to the person who pointed out this oversight to me). > Columns A and B are currently empty. They are intended to hold a > Bugzilla URL and the date on which the bug was filed. > > Jonathan Rudenberg has offered to review the disclosures that have been > posted by CAs so far (thanks Jonathan!), so I've given him edit rights > to the spreadsheet. Jonathan has finished filling in Columns A & B for all of the disclosures he's seen so far. >> Having scanned the crt.sh database, I have produced the following >> spreadsheet. It covers all certificates known to crt.sh where the >> notBefore date is between 30th September 2016(*) and 22nd February >> 2019(**), and where the issuing CA... >> - is currently trusted by Mozilla to issue serverAuthentication >> certificates, and >> - has issued at least 1 certificate with a <64-bit serial number. >> >> https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing >> >> When a value in column E is 100%, this is pretty solid evidence of >> noncompliance with BR 7.1. >> When the values in column E and G are both approximately 50%, this >> suggests (but does not prove) that the CA is handling the output from >> their CSPRNG correctly. >> >> For some issuing CAs, the sample sizes are too small to be able to draw >> any conclusions. >> >> >> (*) This date was chosen because BR 7.1 says: >> "Effective September 30, 2016, CAs SHALL generate non-sequential >> Certificate serial numbers greater than zero (0) containing at least 64 >> bits of output from a CSPRNG." >> >> (**) This is when Wayne started the discussion about DarkMatter, which >> is what prompted the discovery that many CAs were falling short of BR 7.1. > -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote: > On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: >> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: > >>> If any other CA wants to check theirs before someone else does, then now is >>> surely the time to speak up. >> >> Someone else is in the process of checking... ;-) > > The purpose of this survey is to flush out any further CAs that are (or > have been) noncompliant with BR 7.1 but have not yet disclosed an > incident. Columns A and B are currently empty. They are intended to hold a Bugzilla URL and the date on which the bug was filed. Jonathan Rudenberg has offered to review the disclosures that have been posted by CAs so far (thanks Jonathan!), so I've given him edit rights to the spreadsheet. > Having scanned the crt.sh database, I have produced the following > spreadsheet. It covers all certificates known to crt.sh where the > notBefore date is between 30th September 2016(*) and 22nd February > 2019(**), and where the issuing CA... > - is currently trusted by Mozilla to issue serverAuthentication > certificates, and > - has issued at least 1 certificate with a <64-bit serial number. > > https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing > > When a value in column E is 100%, this is pretty solid evidence of > noncompliance with BR 7.1. > When the values in column E and G are both approximately 50%, this > suggests (but does not prove) that the CA is handling the output from > their CSPRNG correctly. > > For some issuing CAs, the sample sizes are too small to be able to draw > any conclusions. > > > (*) This date was chosen because BR 7.1 says: > "Effective September 30, 2016, CAs SHALL generate non-sequential > Certificate serial numbers greater than zero (0) containing at least 64 > bits of output from a CSPRNG." > > (**) This is when Wayne started the discussion about DarkMatter, which > is what prompted the discovery that many CAs were falling short of BR 7.1. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Survey of (potentially noncompliant) Serial Number Lengths
On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: > On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: >> If any other CA wants to check theirs before someone else does, then now is >> surely the time to speak up. > > Someone else is in the process of checking... ;-) The purpose of this survey is to flush out any further CAs that are (or have been) noncompliant with BR 7.1 but have not yet disclosed an incident. Having scanned the crt.sh database, I have produced the following spreadsheet. It covers all certificates known to crt.sh where the notBefore date is between 30th September 2016(*) and 22nd February 2019(**), and where the issuing CA... - is currently trusted by Mozilla to issue serverAuthentication certificates, and - has issued at least 1 certificate with a <64-bit serial number. https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing When a value in column E is 100%, this is pretty solid evidence of noncompliance with BR 7.1. When the values in column E and G are both approximately 50%, this suggests (but does not prove) that the CA is handling the output from their CSPRNG correctly. For some issuing CAs, the sample sizes are too small to be able to draw any conclusions. (*) This date was chosen because BR 7.1 says: "Effective September 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG." (**) This is when Wayne started the discussion about DarkMatter, which is what prompted the discovery that many CAs were falling short of BR 7.1. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
On 15/03/2019 13:26, Peter Gutmann via dev-security-policy wrote:
I actually thought it was from "Chosen-prefix collisions for MD5 and
applications" or its companion papers ("Short chosen-prefix collisions for MD5
and the creation of a rogue CA certificate", "Chosen-Prefix Collisions for MD5
and Colliding X.509 Certificates for Different Identities"), but it's not in
any of those. Even the CCC talk slides only say "We need defense in depth ->
random serial numbers" without giving a bit count. So none of the original
cryptographic analysis papers seem to give any value at all. It really does
seem to be a value pulled entirely out of thin air.
To be honest, I see this as a proxy for competence. Complying with the
spec strictly means you're doing the right thing. Complying with the
spec minus a tiny margin of error for practical reasons means you're
probably fine. Mucking things up due to misunderstood notions of entropy
and thus dropping entropy on the floor means you probably shouldn't be
writing CA software. The fact that the bar was pulled from thin air is
irrelevant; nobody here is suggesting that those using 63 bits of
entropy actually *introduced* a tangible security problem. They just
didn't follow the BR rules, which are there to be followed.
Thus:
a) If you use >64 bits of CSPRNG output raw, you're fine (assuming any
practical CA size).
b) If you use exactly 64 bits of CSPRNG output with duplicate and zero
checks, such that the odds of those checks ever *actually* rejecting a
serial number based on the number of issued certs are < (say) 1%, then
you're fine. For all *practical* intents and purposes you have 64 bits
of entropy.
Ideally you'd have used more bits to avoid risking a duplicate serial
discarding entropy, but at 64 bits, and doing the math for the birthday
problem, the threshold for 1% chance is at about 608 million
certificates [1]. If you've issued less than that number, you have a
less than 1% chance of having ever rejected a single serial number due
to the duplicate check (the zero check is negligible in comparison). It
can be argued that if the problematic code never ran, then it might as
well have never been there. Of course, *proving* that the code never ran
is unlikely to be possible. Ultimately, entropy was reduced by the
presence of that code, even if the outcome was identical to that had it
not been there.
That said, it's quite *reasonable* to write the code this way; no
strange misunderstandings are required. You had 64 bits of entropy and
you applied a required check that negligibly reduced that; it's
certainly better to lose a tiny fraction of a bit of entropy than to
risk a duplicate serial.
c) If you're dropping serials with e.g. the top 8 bits set to zero (as
per Daymion's algorithm), then you very clearly have 63.994353 bits of
entropy, for no good reason. This is problematic, because it clearly
demonstrates a *misunderstanding* of how entropy works and what the
whole point of using 64 bits of raw CSPRNG output is. This is a BR
violation in any strict reading, and readily provable by looking at
serial number distribution.
d) If you're coercing the top bit (EJBCA defaults), then that's clearly
63 bits of entropy, not 64, and of course a BR violation; it doesn't
take a cryptanalyst to realize this, and anyone who isn't trying to
"creatively interpret" the rules to weasel out of admitting
non-compliance can see that 63 < 64 and there's no way to have 64 bits
of entropy in a number where one bit never changes.
[1] See
https://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem :
>>> math.sqrt(2*(2**64) * math.log(1/(1 - 0.01)))
608926881.2334852
--
Hector Martin "marcan"
Public key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
On 15/03/2019 07:13, Jaime Hablutzel via dev-security-policy wrote: 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a CSPRNG with at least one bit in the highest byte set to 1 is, strictly speaking, not true. The best possible implementation for GetRandom64Bits(), as described, only returns 63.994353 bits of entropy, not 64. Can you share how did you get the previous 63.994353?. I'm trying the following and I'm getting a different value: a = 2^64 = 18446744073709551616 b = 0x80 = 36028797018963968 (a - b) / a * 64 = 63.875 Maybe I'm misunderstanding something. Entropy in bits is measured as the log2 of the possible values. So: >>> math.log2(2**64) 64.0 Of 64-bit numbers, 255/256 have at least one bit set in the highest byte (only those starting with 00 don't), so: >>> math.log2(2**64 * 255/256) 63.99435343685886 -- Hector Martin "marcan" Public key: https://mrcn.st/pub ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA records on a CNAME
On 18/03/2019 16:42, Corey Bonnell wrote: Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case). Huh, I hadn't considered that interpretation. Indeed, a strict reading of the RFC suggests that would work. It seems an arbitrary non-defined non-critical CAA tag record should work too (if using an actual iodef is undesirable for some reason). Maybe such a tag should be defined for this purpose? Though this won't help Amazon/Google/etc, as having a higher-level CAA record would require tree-climbing on CNAME targets, which was removed by errata 5065. Sorry for the noise. -- Hector Martin "marcan" Public key: https://mrcn.st/pub ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA records on a CNAME
Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case). Thanks, Corey From: Corey Bonnell Sent: Monday, March 18, 2019 16:42 To: Hector Martin 'marcan'; Jan Schaumann Cc: dev-security-policy@lists.mozilla.org Subject: Re: CAA records on a CNAME Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case). Thanks, Corey From: dev-security-policy on behalf of Hector Martin 'marcan' via dev-security-policy Sent: Monday, March 18, 2019 14:26 To: Jan Schaumann Cc: dev-security-policy@lists.mozilla.org Subject: Re: CAA records on a CNAME On 16/03/2019 10:25, Jan Schaumann via dev-security-policy wrote: > someapp.example.com, over which I have control is a CNAME, so I can't > set a CAA record there. Let's say the CNAME points to > ghs.googlehosted.com. > > Your suggestion is to contact Google and ask them to please add a CAA > record to that domain for a CA that a third-party (to them and myself) > chooses. My experience has been that Google, Akamai, Cloudflare, > Amazon, and Microsoft etc. are not amenable to adding such records. I think part of the problem here is that the CAA specification has no "allow all" option. Third party hosting providers probably want to allow their customers to use any CA they wish, so they lack CAA records. However, there is no way to specify this once you have already encountered a CAA record, so by the time you follow the CNAME, you're stuck. The default CAA behavior can *only* be specified by default, by the absence of records throughout the entire tree. In my optinion this is an oversight in the CAA specification. My use case is different, but somewhat related. I host services for an event under example.com, e.g. .example.com, but I also have a dynamic user.example.com zone (several, actually) where users automatically get a dynamic record assigned at .user.example.com. I use Let's Encrypt for all of the services. Currently I have a CAA record for example.com, but this also locks all the dynamic users into using Let's Encrypt, while I want them to be free to use any CA. I could instead have a CAA record for .example.com, but this is hard to manage and less secure, as it would allow issuance for all nonexistent names and is harder to manage. Ideally I would just set a CAA record for "*" on user.example.com and that would solve the issue, but the current CAA specification has no mechanism for this. If CAA had a way to signal an explicit "allow all", then third party hosting services could signal that on their overall zones in order to solve this problem with CNAMEs (of course, customers who wish to lock down their CAA records for such third-party hosted domains would have to get CAA records added to them, but I think that makes more sense as an explicit thing rather than breaking CNAMEs by default). -- Hector Martin "marcan" Public key: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmrcn.st%2Fpub&data=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435%7C1%7C0%7C636884835910007451&sdata=AvRYycQp7w0zMB2to49mL0MqPdkscrDmw91ePNwKJ5k%3D&reserved=0 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435%7C1%7C0%7C636884835910017456&sdata=OGYmdLZfK8Rktf7N62tUzaJsswMiF64cQF8uGL6eekw%3D&reserved=0 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
