Support dat shortnames via TLS?

[cjb]

The current DNS shortnames have no authentication, so they aren't usable in production. To be comfortable using shortnames, we need a decentralized method of assigning dat hashes to shortnames that has authentication.

I'd guess that TLS is the best way of doing this, even though it's not ideal, since it's already out there, decentralized and authenticated. The path looked up could be:

https://hostless.website/.well-known/dat-url

A TLS result would have to take precedence over a DNS TXT result, otherwise we haven't improved the security of shortnames.

Thanks!

[pfrazee]

This may be a smart decision. It'll be a while before we can add authentication to the dat protocol.

[max-mapper]

been a while since ive looked at the spec but would this technically be WebFinger?

[pfrazee]

@maxogden it is close. Webfinger uses the .well-known path-space, but that's shared by a number of specs.

[pfrazee]

Another option is to HEAD / and include a header in the response

[max-mapper]

@pfrazee ah ok. i didnt like WebFinger a few years ago cause it was XML only but was hoping maybe something better had come out

also, if we're cool inventing specs (vs using dnssec or whatever) we could do a simple stateless message based encrypted udp thing (similar to dns but using sodium)

[pfrazee]

@maxogden You should give Webfinger another look, it's all json now.

We can invent as much as we like within TLS. We need the cert-based authentication.

[cjb]

Another option is to HEAD / and include a header in the response

I think we'd want something that most website owners can achieve. "Put a file here" works approximately anywhere (think e.g. GitHub Pages, Heroku), but anything involving changing HTTP configuration doesn't.

[pfrazee]

Good point

On Wed, Dec 21, 2016 at 4:32 PM, Chris Ball notifications@github.com wrote:

Another option is to HEAD / and include a header in the response

I think we'd want something that most website owners can achieve. "Put a file here" works approximately anywhere (think e.g. GitHub Pages, Heroku), but anything involving changing HTTP configuration doesn't.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/beakerbrowser/beaker/issues/227#issuecomment-268661048, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNhU_C9_HvHOpWJlqKQlvq7N2lWE-jtks5rKakJgaJpZM4LTatX .

[cjb]

Oh, just to get back to something from earlier:

It'll be a while before we can add authentication to the dat protocol.

How would that help with forward resolution of shortnames? I'm having trouble imagining that. (Feel free to point me towards old design docs or whatever.)

[pfrazee]

We havent explored it yet in depth. Specifically, we'd need to authenticate a DNS mapping.

One way to do it is DNSSEC, except the crypto community doesn't love it (weak RSA keys for one, centralization of authority, other easons) and it doesn't have extensive support by TLDs. Another way would be to get certs issued by CAs which can be placed in Dats, but that's obviously going to require some lobbying.

[cjb]

get certs issued by CAs which can be placed in Dats

But that doesn't help you find a Dat from a shortname, right? Once you have a Dat connection open you've already solved the problem of finding out which Dat hash you're looking for, and you're authenticated by its own keypair.

That's why I was confused about how this problem could be solved by adding anything to the Dat protocol. The shortname scheme has to exist outside of the Dat protocol to be useful and decentralized, it seems.

[pfrazee]

But that doesn't help you find a Dat from a shortname, right?

Correct, it helps us authenticate it. You do the shortname lookup => hash via DNS. Then you download the dat site, and check the certfile in the dat. If a trusted CA-chain signature authenticates ownership of the shortname, you're all set.

[pfrazee]

I've put this into a proposal: https://github.com/beakerbrowser/beaker/wiki/Authenticated-Dat-URLs-and-HTTPS-to-Dat-Discovery

[Jermolene]

I like the `.well-known/' idea. Having said that, it's not always convenient to set up an HTTPS web server, and yet one almost always has access to the DNS for custom domains. Might a blob of base64 in a text record be an alternative option?

[pfrazee]

@Jermolene My only reservation is that DNS does not have authentication, so somebody could MITM the lookup

[Jermolene]

@pfrazee ah, yes, you did point that out elsewhere I think. The .well-known/ mechanism is plenty useful enough to be getting on with.

[sull]

could be an opportunity to promote DNSSEC and complimentary tech like DNSCRYPT (https://dnscrypt.org).

[pfrazee]

DNSSEC gets mixed reviews. It might be the right choice in the long run, but for now I think I'd rather use a .well-known

[pfrazee]

Done! https://github.com/beakerbrowser/beaker/pull/275