Skip to content

Suggestion: simplify sets to DNS-based inheritor allowlists and inheritee records #262

Open
@dead-claudia

Description

@dead-claudia

I'm thinking of the following structure, hosted on DNS using two custom resource record types:

These names can change to whatever. I'm not married to them.

  • INHAL: An allowlist of inheritor origins, maintained by inheritee origins.
  • INHOR: An inheritee origin, maintained by inheritor origins.

In order for a requestor origin A.foo.example to share site data with a different origin B.bar.example, the following algorithm must return true:

let origins = dnsQuery("A.foo.example", "INHOR")
if (origins.length === 0) {
    origins = dnsQuery("*.foo.example", "INHOR")
    if (origins.length === 0) {
        return false
    }
}

if (origins[0] !== "B.bar.example") {
    return false
}

let allowed = dnsQuery("B.bar.example", "INHAL")
if (allowed.length === 0) {
    allowed = dnsQuery("*.bar.example", "INHAL")
    if (allowed.length === 0) {
        return false
    }
}

return allowed.some(a => (
    a === "A.foo.example." ||
    a === "*.foo.example."
))

If the above algorithm returns false and data was previously shared, site data for A.foo.example starts from a clean slate. If they all are satisfied and data was not previously shared, sharing begins and it receives access to everything, with old site data cleared. Site data is left intact for B.bar.example in all cases.

Service workers and site caches are never shared. There's probably others that also shouldn't be shared, but that's the main one.

This carries several benefits:

  1. It's an extremely simple list. It's easy to display, easy to make sense of.
  2. It's easy to intervene and deny abusive allowlists. The browser could just intercept the request and replace it.
  3. Unauthorized cross-sote sharing is effectively impossible without compromising the site or compromising its users.
  4. Non-mutually-exclusive associations are not merely impossible, but unrepresentable.
  5. It's very straightforward to migrate site data across domain sets and even alter the sets. It just has to be done incrementally, so everyone's had time to switch.

Using DNS + compulsory DNSSEC adds even more benefits:

  1. The security of the related A/AAAA/CNAME record is equal to that of the allowlist, simplifying security analysis greatly.
  2. Registrars regularly enforce their own, sometimes very stiff, limits on zone count and per-domain record count, and they're not nearly high enough to permit abuse at scale. Some examples:
    • AWS Route53: soft 400 records per type per domain
    • Azure: soft 20 records per type per domain
    • GCP: soft 20 records per type per domain, firm 65533 bytes per query response over TCP
    • Cloudflare: soft 3500 records per domain (no hard limit on enterprise), free tier limited to 200
  3. Doing it through DNS enables fetching concurrently with the entire connection sequence. This drastically reduces latency. Plus, DNS is usually prioritized over HTTP and DNS caches are far more widespread (with even routers commonly having their own caches), speeding up the process even further.
  4. Using custom record types instead of TXT records cuts down on query overhead by a lot, and having separate inheritor and inheritee records makes inheritor lists far easier to query. Also, CDNs commonly enforce a hard limit of 255 characters for TXT records, limiting its utility for domains.
  5. Having to spell out every applicable domain specifically will also make it a technical challenge to scale to millions of sites, even registrar-permitting. Megabyte-long DNS responses will delay page loads significantly, and public DNS servers could have issues dealing with the excessive bandwidth, so there's incentive by those servers' operators to simply censor responses to the problem requests.
  6. Removing inheritor permission for a single domain is extremely easy: just delete the DNS record and let it expire in all the various caches.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions