IPIP-296: DNSLink resolution export with DNSSEC records

[iowaguy]

A full spec of the idea proposed in ipfs/kubo#8799 and ipfs/kubo#6129.

In the current gateway, clients are forced to trust the DNS and IPNS resolutions of the gateway. This proposal reduces the trust needed by a client, and allows honest gateways to prove it is responding truthfully. It does does this by serializing the DNSSEC responses along with the CAR requested by the client.

[lidel]

Thank you for submitting this @iowaguy and apologies it took long to review.
(I discussed this briefly in Iceland with @thibmeu, but this is my proper first pass at this IPIP)

Quick feedback (first pass)

The high level feedback on "How do the components work together" is that in the proposed form, IpfsDnssecChain response it is not flexible enough to allow clients to fully benefit from content-addressing.

Having "all-in-one" (proof+car) type of response is fine, but the spec should also allow for decoupling DNSLink's DNSSEC proof from the data transfer and fetching them separately.

Asks / Rationale

There are additional design constraints that we should include in this spec.

Clients should be able to:

• Fetch DNSSEC proof alone, without content-addressed data
  • cache proof and avoid fetching proof multiple times
  • make smart decisions about which blocks/CIDs should be fetched (data deduplication, using multiple gateways/transports for redundancy)
• Fetch DNSSEC proof for both DNSLink and DNSAddr
  • DNSAddr TXT records work the same as DNSLink ones, but for peer routing. They are optional, but their presence allows fast recovery when HTTP is down, skipping DHT lookup and opportunistically doing bitswap with trusted provider endpoint etc.
• Send a single request and receive end-to-end "DNSLink integrity manifest". This is more than a single DNSSEC proof, because:
  • DNSLinks can be recursive
    • gateway should return integrity proofs for the entire chain up to the final immutable CID (with a limit of 32 jumps or so – that is the resolution limit in Kubo gateway today).
  • DNSLinks can point at mutable /ipns/FQDN or /ipns/KEY
    • this means "DNSLink integrity manifest" should include DNSSEC proofs for all recursive DNSLink TXT records and all Signed IPNS Record (if dnslink=/ipns/KEY was found during the resolution)

[lidel]

💭
If we decouple content-addressed data from DNSSEC proof, then THIS alone could be what the client receives when they request application/vnd.dnslink.dnssec; version=1.

Ensuring this struct is useful to clients (such as web browsers) should be our main focus.

Reusing existing RFC formats where possible is 👍
Will ping some browser folks for review here.

[lidel]

I think the main concern here is that DNSLink's DNSSEC proofs should not be returned with every block or CAR.

The client needs to fetch the proof only once, and the proof, once generated, can be cached for some time. I think this spec should explicitly state that proof can be cached by the gateway for at least 60 seconds, and up to the TTL of the TXT record.

This should mitigate use of proof requests as a surface for DoS.

[thibmeu]

Requiring a minimum TTL could go against DNS behaviour, and adding a new layer of cache should be left to the gateway operator.

[lidel]

Right, I forgot we already talked about his around DNS.MaxCacheTTL.

Ignore my comment then, no special treatment here,
gateway and client should reuse DNS cache around TTL value for TXT record with DNSLink.

[lidel]

💭
re: subresource, if we decouple data from proof response, the problem of subresources goes away: no need to trust gateway did resolution right, the client will fetch root CID block to learn about CID of subresource.

[lidel]

Good point. It would be good to clearly state the scope of this Version 1 spec.

Sidenote: context on recursive DNSLinks

If the DNSLink value is /ipfs/.. then the story is simple, we have two distinct stages of resolution and DNSSEC proof closes the gap, allowing clients to display end-to-end integrity indicators:

flowchart LR
    dnslink=/ipfs/CID-->/ipfs/CID
    subgraph DNSSEC
      example.com-->dnslink=/ipfs/CID
    end
    subgraph IPFS
    /ipfs/CID-->DAG
    DAG-->blocks
    end

Loading

If we add /ipns/ to the picture, that namespace requires an additional resolution step: /ipns/ path can point at an IPNS KEY or another domain name (FQDN), which requires doing recursive DNSLink resolution. This resolution creates more complexity and potential gap around client's ability to verify signed IPNS records (KEY ones):

To illustrate:

flowchart TB
    dnslink=/ipfs/CID-->/ipfs/CID
    FQDN-->dnslink=/ipns/KEY
    dnslink=/ipns/KEY-->/ipfs/CID
    dnslink=/ipns/KEY-->/ipfs/CID
    /ipns/FQDN-->FQDN
    /ipns/KEY-->/ipfs/CID
    
    subgraph DNSSEC
      FQDN-->dnslink=/ipfs/CID
      FQDN-->dnslink=/ipns/KEY
      FQDN-->dnslink=/ipns/FQDN
    end
    subgraph IPNS    
      dnslink=/ipns/KEY-->/ipfs/CID
      dnslink=/ipns/KEY-->/ipns/KEY
      dnslink=/ipns/KEY-->/ipns/FQDN
      dnslink=/ipns/FQDN-->/ipns/FQDN

     
    end
    subgraph IPFS
      /ipfs/CID-->CID
      CID-->DAG
      DAG-->blocks
    end

Loading

What to do with /ipns/ ?

For Version 1, we could say the /ipns/ gap is out of the scope and needs to be resolved client-side.

I think we don't need to worry about dnslink=/ipns/FQDN – client will be able to send follow-up DNSSEC proof requests for the new FQDN, and do that recursive dance until a non-DNS, cryptographically verifiable path is found.

Open problem / need for spec: fetching signed IPNS records from Gateway

I think Gateways should support a scenario where dnslink=/ipns/KEY.
Many clients won't be able to retrieve IPNS records (no p2p, no dht), and asking clients to implement delegated routing via separate protocol like reframe (allowing light clients to fetch Signed IPNS Records) may be a stretch for many.

I think the Gateway should provide a way for a client to request IPNS proof (signed IPNS record) in a way that is as easy as requesting a DNSSEC one.

Details TBD, but my initial take is that either

• "IPNS proof" should be a separate request-response type, allowing clients to resolve and cache IPNS resolutions independently, or

• part of unified application/vnd.dnslink.integrity; version=1 response that returns both DNSSEC proof and (optional) IPNS signed record, broad strokes:

  struct DnslinkIntegrity {
    DnssecProofs dnssecProofs;
    SignedIPNSRecords ipnsRecords;
  }
  struct DnssecProofs {
    uint32 length;
    IpfsDnssecChain chains[length];
  }
  struct SignedIPNSRecords {
    uint32 length;
    IPNSRecord records[length];
  }

To make things easier for light clients, we should lean towards the latter one. A single request-response made by a thin client that can be cached for the duration of the retrieval session.

[lidel]

💭
Needs clarification: since "Reduced TLS DNSSEC Chain Extension" here is based on RFC 9102, does it also include setting dnssec_chain flag on request's TLS handshake?

My feedback here is that custom TLS is a very big ask for everyone to implement, and limits the utility of DNSLink proofs on Gateways, especially given they can be decoupled from retrieving content-addressed data. Ok to experiment, but we should always have a plain way for fetching them without messing with TLS layer.

[thibmeu]

The Reduced TLS DNSSEC Chain Extension is an experimental RFC, which has inspired some of the design in this IPIP. There is no ask for gateways to implement a custom TLS layer.

[lidel]

We've discussed this last week, and my understanding of next steps is that Cloudflare will prototype DNSSEC proofs as an extension of DNS-over-HTTPS specification.
This will be independent of IPFS, and have utility beyond securing DNSLink TXT records.

When that thing exists, we can get back to this discussion, and see if Gateways could reuse that work and expose the same proofs for DNSLinks, and also include signed IPNS records (covering entire /ipns/ proof space).

@iowaguy is it ok to close this PR for now, or do you want to keep it as draft?

[iowaguy]

That is my understanding as well. I think this is okay to close!

…

On Thu, Aug 18, 2022, at 10:42, Marcin Rataj wrote: ***@***.**** requested changes on this pull request. We've discussed this last week, and my understanding of next steps is that Cloudflare will prototype DNSSEC proofs as an extension of DNS-over-HTTPS specification. This will be independent of IPFS, and have utility beyond securing DNSLink TXT records. @iowaguy <https://github.com/iowaguy> is it ok to close this PR for now, or do you want to keep it as draft? — Reply to this email directly, view it on GitHub <#296 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVYRZMTXMBT6BPJB6GNJUTVZZKXRANCNFSM5227PREA>. You are receiving this because you were mentioned.Message ID: ***@***.***>