GOpenCDR security and disclosure policy

How this relates to the Gelhaus Solutions policy

GOpenCDR is covered by Gelhaus Solutions' vulnerability disclosure policy, and everything in it applies here: how to report, the response times, the safe harbour, credit and identifiers. This page adds what is particular to a namespace: what is in scope, what matters most, and what testing must never do, because a root and its resolvers serve people who never agreed to be part of a test.

GOpenCDR is part of the scope of the Gelhaus Solutions CVE Numbering Authority programme, and identifiers are assigned as the disclosure policy describes.

How to report

Email egelhaus@ennogelhaus.de, or file the report through GAdvisory. Both reach the same person and start the same process. For anything sensitive, encrypt with the key published for ennogelhaus.de over WKD; its fingerprint is on the disclosure policy. Please do not open a public issue.

Put "GOpenCDR" in the subject line, and "urgent" as well where the report concerns key material, the root or the IANA rule. Those are read first.

GOpenCDR's security.txt, at https://cdr.gplatform.org/.well-known/security.txt, points to this page, and so does the footer of every GOpenCDR page.

What is in scope

• The portal, the API and RDAP under cdr.gplatform.org.
• The DNS plane: the signer, zone generation and publication, our authoritative servers, the mirror agent, the prober and gocdrctl.
• The transparency log, its checkpoints and the tools that verify them.
• The public resolver we run, dns.cdr.gplatform.org.
• The publication of trust anchors and anchor bundles.
• The browser extension and the desktop and mobile clients.
• The GOpenCDR certificate authority and its certificate transparency log.

What we most want to hear about

1. Anything that could make a resolver following GOpenCDR answer for a name that exists in the IANA root, or that weakens any of the three layers enforcing that rule: the root's verification gate, the blocklist and the mirror agent.
2. Any way to obtain a signature other than through the signer's intended path, to extract or export a key, or to make the signer sign something the gate should have refused.
3. Any way to get a root change through without the approval it needs, to approve one's own request, or to skip the 24-hour wait of an approval made alone.
4. Any way to make the transparency log show different histories to different people, or to make a verifier accept an entry or a checkpoint it should refuse.
5. Any way to serve a zone that fails its ZONEMD or DNSSEC check, or to make a mirror accept one.
6. Any way to impersonate a mirror agent, to replay one of its signed requests, or to obtain TLD zone files without enrolment.
7. Registrant data exposed where RDAP should redact it, and any way into somebody else's account.
8. Any certificate from the GOpenCDR certificate authority for a name outside its name constraints, or any way around them.

Rules for testing

The namespace serves people who never agreed to be tested on, so research here has rules of its own, on top of those in the disclosure policy.

• Test against your own account, your own names and your own mirror. For the test TLD gelhaus, ask for an invitation to test with.
• No denial of service. Do not load-test, flood or try to exhaust our resolvers, our authoritative servers, the API or the portal, and do not use any of them to reflect or amplify traffic at anybody.
• Do not poison caches or hijack names in resolvers you do not operate, ours included.
• Do not test the IANA root, other namespaces, or infrastructure run by TLD operators or mirror operators without their permission.
• Access only what you need to show the problem. If you reach other people's data, stop, keep none of it, and tell us.
• No social engineering of our staff or of operators, no physical attacks, and nothing aimed at our own hardware, including the key store and the network behind it.
• Keep the details private until the coordinated date.

Research within these rules is welcome, and the safe harbour in the disclosure policy covers it.

What is out of scope

• Findings in third-party software we run unmodified, such as Knot DNS, NSD, Unbound, dnsdist, HashiCorp Vault, Temporal or NATS. Report those to the project; we will help, and we will apply the fix.
• Weaknesses of the DNS protocol itself with no impact particular to GOpenCDR.
• The IANA root, OpenNIC and Handshake.
• Findings that need an already compromised device, administrative access to a mirror you do not operate, or a victim who installs something unusual, unless GOpenCDR makes them worse.
• Output of automated scanners without a demonstrated impact, missing headers without an impact, and rate limits working as described.
• Abuse under a GOpenCDR name, such as phishing, which goes to the abuse route in the acceptable use policy.

If a key may be compromised

If you believe a signing key, a trust anchor or the transparency log's key may be exposed, write at once, with "Key" in the subject line. Tier 0 can act immediately under its emergency procedure, which may only suspend or tighten, never loosen. Every emergency action is published in the transparency log and reviewed afterwards.

Problems that are not vulnerabilities

A resolution failure, a bogus answer or a signature about to expire is not always a vulnerability, but we want to hear about it just as quickly. Write to the same address.