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
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%2Fpubdata=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435%7C1%7C0%7C636884835910007451sdata=AvRYycQp7w0zMB2to49mL0MqPdkscrDmw91ePNwKJ5k%3Dreserved=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-policydata=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435%7C1%7C0%7C636884835910017456sdata=OGYmdLZfK8Rktf7N62tUzaJsswMiF64cQF8uGL6eekw%3Dreserved=0 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
