Skip to content
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

DNS proofs #367

Closed
malgorithms opened this issue Mar 26, 2014 · 12 comments
Closed

DNS proofs #367

malgorithms opened this issue Mar 26, 2014 · 12 comments

Comments

@malgorithms
Copy link
Contributor

Now that we have website proofs done (#28), we should talk about how we'll do DNS right.

@maxtaco
Copy link
Contributor

maxtaco commented Mar 27, 2014

How about just posting a TXT entry:

keybase-verification=SomeRandomBase64FingerprintWhichIsSHA512ofASignature

@dgw
Copy link

dgw commented Mar 28, 2014

TXT entries are underrated little things.

Could even be on a false hostname (perhaps optionally), e.g. _keybase.domain.tld

@sndrsmnk
Copy link

DNS is insecure. This must rely on DNSSEC. (edit: or, well, it would be nice...)

@zQueal
Copy link

zQueal commented Mar 28, 2014

I think this user really hit the nail on the head in this post. However, to get the ball rolling, I'm more than okay with putting my vote towards TXT DNS verification; assuming it works correctly.

For example, I, like many of my compatriots host DNS with CloudFlare, and even sometimes HE.NET because they are both very fast and very secure. So, just keep that in mind.

@malexmave
Copy link

DNSSEC would be sweet, but as it is currently impossible to get decent Hosting with DNSSEC for many TLDs (I spent a few days searching for a hoster for .de with DNSSEC and came up blank), I think it would be a bad idea to REQUIRE it.

Perhaps there could be an extra indicator on the website and in the client if DNSSEC is available, a bit like the "Verified Account"-Badge on Twitter, stating that this record is verified using DNSSEC for added certainty that it is correct.

@maxtaco
Copy link
Contributor

maxtaco commented Mar 30, 2014

The backend of DNS (via TXT) is largely ready to go.

Agreed @malexmave; DNSSEC is better but might not be supported enough yet.

@maxtaco
Copy link
Contributor

maxtaco commented Mar 30, 2014

Also, it seems like we would have to implement dnssec ourselves in JS, since node doesn't support it yet.

@ghost
Copy link

ghost commented Apr 2, 2014

I'm not sure it's worth the effort to create a keybase-DNS TXT authentication loop specifically, when we already have PGP and DNSSEC. It seems like it would be much more worthwhile to standardize a way of publishing PGP keys in signed zones, so as to make keyservers entirely redundant.

@malexmave
Copy link

There are already some ways to do that. It's just not very widely used.

@maxtaco
Copy link
Contributor

maxtaco commented Apr 9, 2014

Live!

@maxtaco maxtaco closed this as completed Apr 9, 2014
@zQueal
Copy link

zQueal commented Apr 9, 2014

Suggestion:

Instead of hosting a web page, you can edit a DNS TXT record. If you control the DNS for a domain, but not a website, this should be an easy alternative. By "easy" we mean simple but at the mercy of your DNS interface.

Change Instead of hosting a web page, to Instead of hosting a text file,.

@malexmave
Copy link

Also, you did not add the new keyword "dns" to keybase prove -h:

usage: keybase prove [-h] [-f] [-o OUTPUT] service [remote_name]

Positional arguments:
  service               the name of service; can be one of: {twitter,github,
                        web}
  remote_name           username or hostname at that service

Optional arguments:
  -h, --help            Show this help message and exit.
  -f, --force           don't stop for any prompts
  -o OUTPUT, --output OUTPUT
                        output proof text to file (rather than standard out)

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

No branches or pull requests

6 participants