New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DNS DEP #25

Merged
merged 6 commits into from May 16, 2018

Conversation

Projects
None yet
4 participants
@pfrazee
Member

pfrazee commented Apr 27, 2018

Ready for review!

@pfrazee pfrazee referenced this pull request Apr 30, 2018

Closed

Upcoming Meeting Agenda - 2 May 2018 #18

3 of 6 tasks complete
@pfrazee

This comment has been minimized.

Member

pfrazee commented May 2, 2018

Do we want to think about a procedure for DNS wildcards? Something where, when that matches, you open the wildcard dat and then lookup the subdomain record in its content?

- Client checks its names cache. If a non-expired entry is found, return with the entry.
- Client issues a DNS TXT request for `name`. This request should be issued via a secure transport (see ["DNS-over-HTTPS"](#dns-over-https)).
- Client iterates all TXT records given (skip if none). If a record's value matches the RegExp `^dat:\/\/[0-9a-f]{64}\/?$`:

This comment has been minimized.

@mafintosh

mafintosh May 2, 2018

The TXT record is a series of key=values itself. We should pick a key here here that contains the dat key.

@bnewbold

My only blocking request is for a privacy/security section. This section should lay out assumptions and a trust model (who is trusted? what information is considered public or private?), and address the privacy difference between approaches (or this could be expanded on in the Alternatives).

As comments (but not blocking things that need to be addressed): i'm sad that there are basically only large hyper-centralized DNS-over-HTTP providers today (google and cloudflare).

A little concerned about semantic confusion to users between addressing-by-name and addressing-by-key/hash: the names are more usable, but have different security/robustness properties and it's confusing to have to explain the difference (hashes are already confusing). From a robustness/archival/scholarly/fixing-the-broken-web perspective, it's also really nice to use opaque strong links (aka, hashes) instead of DNS names that change hands, become un-registered, and suffer "content drift".
My preference would be to encourage folks to use hash-style links and address the confusion challenge head-on.
(This isn't a new thing with this proposal, just commenting my feels on using names in general. I think the human-naming challenge should be kept modular; aka Dat should not try to solve this in a Dat-specific way, the dweb community/ecosystem should try to solve this in a general way that will help all projects).

cryptographic keys. In the context of Web browsers, a URL scheme is used which
is structured as `'dat://' {key} '/' {path...}`.
This DEP describes an additional protocol Dats using DNS short names.

This comment has been minimized.

@bnewbold

bnewbold May 2, 2018

Contributor

Grammar? "an additional protocol for referencing Dat archives"?

# DNS-over-HTTPS
[dns-over-https]: #dns-over-https
Until PKI can authenticate the DNS lookups (ie via SSL certificates or equivalent) there is a risk that the DNS lookup will be intercepted by an adversary. To protect against this, the client should use DNS-over-HTTPS to lookup the DNS TXT records.

This comment has been minimized.

@bnewbold

bnewbold May 2, 2018

Contributor

I think the "should" "MUST" be defined better here, a la an IETF RFC. Is it a nice to have, a best practice, the norm, or the entire basis of this proposal? Eg, if possible, should DNS servers refuse to send dat URLs over non-HTTPS?

The goal of this DEP is to leverage DNS to provide human-readable shortnames which map to Dat's cryptographic addresses. The solution...
- Must provide a single canonical Dat URL for the domain. It should not be possible for a name to have multiple valid mappings. (No conflict.)

This comment has been minimized.

@bnewbold

bnewbold May 2, 2018

Contributor

This surely won't be the case over time though, right? At the very least domains change ownership. I think the TTL (mentioned below) defines the expected validity period of the mapping.

Also, as a though experiment, might somebody some day want to have geo-targeted "translated" dats mapped to the same domain for different regions (in different languages)? Maybe not.

This comment has been minimized.

@pfrazee

pfrazee May 7, 2018

Member

The point about "No conflict" is that there should be a well-defined solution for getting a single global mapping. I'm not sure I consider cache-freshness to be a factor there: that's more a question of consistency strictness.

I'm not sure geo-targeted dats should be handled at the names layer but it's an interesting idea.

- Return the entry.
- Client issues an HTTPS GET request to `https://{name}/.well-known/dat`.
- If the server responds with a `404 Not Found` status, client stores a `null` entry in the names cache with a TTL of 3600 and returns a failed lookup.
- If the server responds with anything other than a `200 OK` status, return a failed lookup.

This comment has been minimized.

@bnewbold

bnewbold May 2, 2018

Contributor

To be explicit, this means no retries or following of redirects (3xx)? This makes the scheme more brittle than normal HTTP behavior. As a concrete example, all archive.org downloads redirect from archive.org/download/some-item/some-file.txt to the specific storage server using an HTTP redirect. .well-known might not seem like the sort of thing that would need redirects to us today, but it might be something folks want or expect or need in the future.
I'm not entirely sure what the right thing to do here is; allowing redirects could make reasoning about behavior harder.

@pfrazee pfrazee referenced this pull request May 2, 2018

Closed

Action Items - Meeting #9 (2 May) #20

8 of 17 tasks complete
@pfrazee

This comment has been minimized.

Member

pfrazee commented May 7, 2018

Added a "Security and Privacy" section, and rewrote the DNS TXT record to use the following schema:

DATKEY={key}

I chose that keyname because the existing DNS record types do a similar app-specific prefix (IPSECKEY, OPENPGPKEY) but I'm open to discussion.

@RangerMauve

This comment has been minimized.

Contributor

RangerMauve commented May 7, 2018

I like the DATKEY= prefix. IPNS uses something similar with dnslink=

@pfrazee pfrazee merged commit 1efa859 into datprotocol:master May 16, 2018

@pfrazee pfrazee deleted the pfrazee:dns-dep branch May 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment