bitcoin DNS addresses
15 messages, 26 to 30 Jul 2011. Started by Rick Wesson.
Rick Wesson (5), Matt Corallo (5), Luke Dashjr (2), John Smith, phantomcircuit, Mike Hearn
I've just joined the list with the goals of producing a patch to sendtoaddress in rpc.cpp to support DNS lookups so that one could publish a TXT record in the DNS with their wallet address to facilitate sending of coin.
I'm proposing something like the code below, which works but needs additional error handling.
also working on a internet-draft to describe how to put bitcoin addresses in the DNS which I hope to post the first draft of this week.
I'd appreciate comments on issues around annomity, community push back and any other issues you might have with leveraging the DNS for bitcoin transactions.
thanks,
-rick
Value sendtoaddress(const Array& params, bool fHelp)
{
if (fHelp || params.size() < 2 || params.size() > 4)
throw runtime_error(
"sendtoaddress <bitcoinaddress> <amount> [comment]
[comment-to]\n"
"<amount> is a real and is rounded to the nearest 0.00000001");
/** ; <<>> DiG 9.7.3 <<>> _btc.rick.wesson.us txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43754 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;_btc.rick.wesson.us. IN TXT
;; ANSWER SECTION: _btc.rick.wesson.us. 300 IN TXT "BTC=1; 1GCVXLfF1TcpnnDLJRHk845NZhuJWQTnUD"
;; Query time: 143 msec **/
string strAddress = params[0].get_str();
string dname="_btc.";
if(strAddress.find("@")){
unsigned char answer[255];
int len=0;
dname.append(strAddress);
dname.replace(dname.find("@"), 1, ".");
if((len = res_query(dname.c_str(), C_IN, T_TXT, answer, PACKETSZ)) <
0) {
string dnsAnswer=(char*)answer;
int i=dnsAnswer.find("BTC=1;");
if( i < 0) throw runtime_error( dname + " is not associated with a
bitcoin address");
i += 6;
i = dnsAnswer.find("1", 6) ; // address start with a one (1)
dnsAnswer.erase(0,i);
strAddress=dnsAnswer;
}
} // Amount int64 nAmount = AmountFromValue(params[1]); ...
On Mon, 2011-07-25 at 17:29 -0700, Rick Wesson wrote:
Quoted text (4 lines)
> I've just joined the list with the goals of producing a patch to > sendtoaddress in rpc.cpp to support DNS lookups so that one could > publish a TXT record in the DNS with their wallet address to > facilitate sending of coin.
But...why? Using URIs is much simpler and can be more useful in terms of being able to give different addresses and/or values per user. Also, despite DNSSec being "out there" DNS is still very insecure to transmit something that will result in money transfer...some idiot tries it on public WiFi and a MITM steals your coins...DNS is really just not well suited for this kind of thing. If you want nice name->address mapping, a simple HTTPS server with addresses and client support (there are some patches around for this) works much better in the end.
Matt,
I started from the premise that I can't remember a bitcoin address but I can/do remember email addresses which, as an identity are easy labels for humans to remember. The IPv4 address is the metaphor I consider. As someone who actually worked on parts of DNSSEC I do believe in it -- and that it offers reasonable security for transactions.
Remember MITM attacks on DNS for a transaction are for the sender against the merchant, and it is only the wallet ID that would be available. These identifiers are something people use "like" an identity in that they are frequently shared in public spaces.
Also, a DNS mapping does not prevent or deny anyone from leveraging HTTP(S) for simular mapping. My point is that DNS is designed for name to thing mapping and its done a decent job. What I like about the DNS is that it is frequently leveraged as a proxy for identity and http URIs are not. Where https://wesson.us/ricks-bitcoin-address doesn't feel like and identity (to me) and rick.wesson.us does.
My point is about usability and user experience. Bitcoin if used in the DNS might make DNSSEC more popular which IMHO is a good thing.
-rick
On Mon, Jul 25, 2011 at 6:35 PM, Matt Corallo <bitcoin-list@bluematt•me> wrote:
Quoted text (29 lines)
> On Mon, 2011-07-25 at 17:29 -0700, Rick Wesson wrote: >> I've just joined the list with the goals of producing a patch to >> sendtoaddress in rpc.cpp to support DNS lookups so that one could >> publish a TXT record in the DNS with their wallet address to >> facilitate sending of coin. > > But...why? > Using URIs is much simpler and can be more useful in terms of being able > to give different addresses and/or values per user. > Also, despite DNSSec being "out there" DNS is still very insecure to > transmit something that will result in money transfer...some idiot tries > it on public WiFi and a MITM steals your coins...DNS is really just not > well suited for this kind of thing. > If you want nice name->address mapping, a simple HTTPS server with > addresses and client support (there are some patches around for this) > works much better in the end. > > ------------------------------------------------------------------------------ > Magic Quadrant for Content-Aware Data Loss Prevention > Research study explores the data loss prevention market. Includes in-depth > analysis on the changes within the DLP market, and the criteria used to > evaluate the strengths and weaknesses of these DLP solutions. > http://www.accelacomm.com/jaw/sfnl/114/51385063/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
On Monday, July 25, 2011 11:35:34 PM Rick Wesson wrote:
Quoted text (6 lines)
> I started from the premise that I can't remember a bitcoin address but > I can/do remember email addresses which, as an identity are easy > labels for humans to remember. The IPv4 address is the metaphor I > consider. As someone who actually worked on parts of DNSSEC I do > believe in it -- and that it offers reasonable security for > transactions.
1. Right now you practically need a unique Bitcoin address per transaction. 2. DNSSEC is on the edge of becoming illegal in the US. 3. Emails aren't merely domains.
I would propose something like resolving foo@bar•net to a SRV lookup for _bitcoinaddressresolution._tcp.foo.bar.net, expecting a cert for bar.net, making a HTTPS request for /bitcoinaddressresolution?foo@bar•net, and also sending an email to foo@bar•net (the usual way) signed with the keys used for the transaction. ;)
Quoted text (2 lines)
> > 1. Right now you practically need a unique Bitcoin address per transaction.
I'd like to find ways to alievate this requirement.
Quoted text (1 line)
> 2. DNSSEC is on the edge of becoming illegal in the US.
really, pointers please. DHS was a huge funder for DNSSEC asn .mil was the first domain to deploy it. I think you may be miss-informed.
Quoted text (1 line)
> 3. Emails aren't merely domains.
correct, I was speaking about an "address" that used the same/simular formatting but did not use the SMTP protocol.
-rick
Quoted text (6 lines)
> I would propose something like resolving foo@bar•net to a SRV lookup for > _bitcoinaddressresolution._tcp.foo.bar.net, expecting a cert for bar.net, > making a HTTPS request for /bitcoinaddressresolution?foo@bar•net, and also > sending an email to foo@bar•net (the usual way) signed with the keys used for > the transaction. ;) >
On Tuesday, July 26, 2011 12:54:23 AM Rick Wesson wrote:
Quoted text (4 lines)
> > 1. Right now you practically need a unique Bitcoin address per > > transaction. > > I'd like to find ways to alievate this requirement.
Admittedly, my proposal to email a signed message allows one to reuse addresses, but there is still a privacy concern.
Quoted text (4 lines)
> > 2. DNSSEC is on the edge of becoming illegal in the US. > > really, pointers please. DHS was a huge funder for DNSSEC asn .mil was > the first domain to deploy it. I think you may be miss-informed.
http://www.google.com/search?q=%22PROTECT+IP+act%22+DNSSEC
Quoted text (4 lines)
> > 3. Emails aren't merely domains. > > correct, I was speaking about an "address" that used the same/simular > formatting but did not use the SMTP protocol.
I only meant that foo.bar.net is not the same formatting. foo@bar•net would be.
Quoted text (3 lines)
> I only meant that foo.bar.net is not the same formatting. > foo@bar•net would be. >
Yes please use email-like addresses, whatever is decided on the underlying protocol.
JS
On Mon, 2011-07-25 at 20:35 -0700, Rick Wesson wrote:
Quoted text (13 lines)
> Matt, > > I started from the premise that I can't remember a bitcoin address but > I can/do remember email addresses which, as an identity are easy > labels for humans to remember. The IPv4 address is the metaphor I > consider. As someone who actually worked on parts of DNSSEC I do > believe in it -- and that it offers reasonable security for > transactions. > Remember MITM attacks on DNS for a transaction are for the sender > against the merchant, and it is only the wallet ID that would be > available. These identifiers are something people use "like" an > identity in that they are frequently shared in public spaces. >
Yes, DNSSEC is great if you are running your own recursive name server. However, that is probably something like 0.01% of the people out there. If this were to be made secure, one would have to implement a full recursive nameserver inside of Bitcoin with the root trust anchors hardcoded in. This seems like way overkill to do name->address mapping. (My attack scenario here is coffee shop wifi with the default DNS resolvers being somewhere at the ISP and a ARP (or other) MITM attack intercepting and playing with your DNS queries). Additionally, HTTPS mapping offers some advantages such as ease of offering up different to different people by eg. IP address (could be done by setting DNS TTL to 0 and assuming all users will be using a built-in resolver, but its still not guaranteed that other clients would use a built-in resolver and then the IP of the resolver is not the same as the IP of the Bitcoin node). Not that DNS is a terrible idea, but there are clear advantages for using HTTPS (or similar) mapping over DNS and I see no clear advantage for using DNS over HTTPS (aside from the "that is what it is designed for" argument, which I would claim is an invalid argument as you have to consider the technology, not its intent).
Quoted text (9 lines)
> Also, a DNS mapping does not prevent or deny anyone from leveraging > HTTP(S) for simular mapping. My point is that DNS is designed for name > to thing mapping and its done a decent job. What I like about the DNS > is that it is frequently leveraged as a proxy for identity and http > URIs are not. Where https://wesson.us/ricks-bitcoin-address doesn't > feel like and identity (to me) and rick.wesson.us does. > > My point is about usability and user experience. Bitcoin if used in > the DNS might make DNSSEC more popular which IMHO is a good thing.
Hold on there, Bitcoin is still tiny, I highly, highly doubt it will make a difference to DNSSEC adoption.
For some reason my mail client is being thick and not responding on-list, sorry about that...
On Tue, 2011-07-26 at 08:34 -0700, Rick Wesson wrote:
Quoted text (16 lines)
> > Most OSes dont do any resolving at all, they just query upstream > > resolvers. In the case of the coffee shop, that upstream resolver is > > the attacker. This attacker can easily just claim that the zone you > > requested is not DNSSEC signed and return their data and the OS will not > > be any wiser. AFAIK, most OSes dont have a mechanism to require the > > zone queried is DNSSEC signed meaning you have to implement a full DNS > > resolver in Bitcoin in order for it to be secure. > > Matt, > > The same attack can apply to https with a self signed cert where it is > the A record that is replaced by the attacker and the https request is > sent to evil.com's server which responds to the request with an answer > in the form you expect. This is what lots of malware does on windows > to steel bank login credentials, securing http doesn't prevent such an > attack.
If you are using a self-signed cert to do any kind of important data transfer you are just being stupid. Here I am assuming your computer isnt actually compromised, but only the network is, which I think is a fairly good assumption.
Quoted text (10 lines)
> > Windows has supported DNSSEC since 2008 as have most of the unix > variants, mac osx since 10.3 Android also seems to include DNSSEC > capable resolvers. > > If this thread is really about DNSSEC then we might move it to a more > appropriate forum for discussing how applications leverage DNS > security extensions. Its taken some years to get the specs done and > the root signed I expect it to take many more to enable the > applications to leverage the deployed infrastructure.
No, DNSSEC is very well done, this thread is specifically about the security implications of using DNSSEC for Bitcoin address communication. IMO it is not a good idea, as for it to be secure against a coffee-shop network MITMer you have to implement a full resolver with root trust anchors and knowledge of root servers in Bitcoin, which does not seem like a good idea.
Quoted text (5 lines)
> > I am interested in working on the issues surrounding usability and I > find that remembering and communicating a bitcoin address are current > limiting factors in the acceptance and deployment of this software. My > goal is for simpler user experience.
I totally agree, however I don't think DNS-based resolving is a good idea here. HTTPS does have several advantages over a DNSSEC-based solution without any significant drawbacks that I can see.
Matt
dns resolution is far simpler to implement than properly checking the https certificate chain
Matt Corallo <bitcoin-list@bluematt•me> wrote:
Quoted text (61 lines)
>For some reason my mail client is being thick and not responding >on-list, sorry about that... > >On Tue, 2011-07-26 at 08:34 -0700, Rick Wesson wrote: >> > Most OSes dont do any resolving at all, they just query upstream >> > resolvers. In the case of the coffee shop, that upstream resolver is >> > the attacker. This attacker can easily just claim that the zone you >> > requested is not DNSSEC signed and return their data and the OS will not >> > be any wiser. AFAIK, most OSes dont have a mechanism to require the >> > zone queried is DNSSEC signed meaning you have to implement a full DNS >> > resolver in Bitcoin in order for it to be secure. >> >> Matt, >> >> The same attack can apply to https with a self signed cert where it is >> the A record that is replaced by the attacker and the https request is >> sent to evil.com's server which responds to the request with an answer >> in the form you expect. This is what lots of malware does on windows >> to steel bank login credentials, securing http doesn't prevent such an >> attack. >If you are using a self-signed cert to do any kind of important data >transfer you are just being stupid. Here I am assuming your computer >isnt actually compromised, but only the network is, which I think is a >fairly good assumption. >> >> Windows has supported DNSSEC since 2008 as have most of the unix >> variants, mac osx since 10.3 Android also seems to include DNSSEC >> capable resolvers. >> >> If this thread is really about DNSSEC then we might move it to a more >> appropriate forum for discussing how applications leverage DNS >> security extensions. Its taken some years to get the specs done and >> the root signed I expect it to take many more to enable the >> applications to leverage the deployed infrastructure. >No, DNSSEC is very well done, this thread is specifically about the >security implications of using DNSSEC for Bitcoin address communication. >IMO it is not a good idea, as for it to be secure against a coffee-shop >network MITMer you have to implement a full resolver with root trust >anchors and knowledge of root servers in Bitcoin, which does not seem >like a good idea. >> >> I am interested in working on the issues surrounding usability and I >> find that remembering and communicating a bitcoin address are current >> limiting factors in the acceptance and deployment of this software. My >> goal is for simpler user experience. >I totally agree, however I don't think DNS-based resolving is a good >idea here. HTTPS does have several advantages over a DNSSEC-based >solution without any significant drawbacks that I can see. > >Matt > >------------------------------------------------------------------------------ >Magic Quadrant for Content-Aware Data Loss Prevention >Research study explores the data loss prevention market. Includes in-depth >analysis on the changes within the DLP market, and the criteria used to >evaluate the strengths and weaknesses of these DLP solutions. >http://www.accelacomm.com/jaw/sfnl/114/51385063/ >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge•net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[snip]
Quoted text (3 lines)
> I totally agree, however I don't think DNS-based resolving is a good > idea here. HTTPS does have several advantages over a DNSSEC-based > solution without any significant drawbacks that I can see.
To restate your (con dnssec) points:
o DNS resolution of bitcoin addresses is bad because of potential
MITM attacks
o DNSSEC is not a security measure for mitigating DNS resolution of
bitcoin addresses
because the application would require its own dnssec enabled stub resolver
Please restate o HTTPS is your preferred method for resolution because?
If you can enumerate your advantages so I can develop a proper response to the points you have raised.
thanks,
-rick
On Tue, 2011-07-26 at 09:50 -0700, Rick Wesson wrote:
Quoted text (12 lines)
> [snip] > > > I totally agree, however I don't think DNS-based resolving is a good > > idea here. HTTPS does have several advantages over a DNSSEC-based > > solution without any significant drawbacks that I can see. > > To restate your (con dnssec) points: > o DNS resolution of bitcoin addresses is bad because of potential > MITM attacks > o DNSSEC is not a security measure for mitigating DNS resolution of > bitcoin addresses > because the application would require its own dnssec enabled stub resolver
That is one point, but yes.
Quoted text (3 lines)
> > Please restate > o HTTPS is your preferred method for resolution because?
Because it allows for the giving of different addresses to each client based on IP much easier. Its possible with DNS by setting TTL to 0 and hoping that Bitcoin clients will be using their own resolver, but that is far from guaranteed. Additionally, HTTPS stuff has already been coded and implemented, so there's that...
Frankly, HTTPS' advantages are very small here, but since they exist, and DNS has no advantages that I can see, I don't see any reason to go with DNS here. I much prefer using a HTTPS library (of which there are many which have had much more thorough security audits) than a DNSSEC-implementing DNS recursion library with the root trust anchors and root servers built-in (are there any?).
Maybe I'm missing something here?
Matt
This was already discussed on the forums, but clear use cases would be helpful.
I originally thought this feature seemed like a no-brainer, but randomly emailing money to people out of the blue is not a very common operation. You almost always have contact with them first, if only to say "hey, I'm going to send you some money", but more commonly to figure out how much you're going to pay and what for.
Once you have communication, providing an address in-band isn't very hard, and it has the advantage of always working. Doing anything with DNS or magic HTTPS endpoints means that 90% of the time, your feature *will not work* (eg it won't work for any gmail/yahoo/hotmail account) and users will rapidly learn not to bother trying as they have no way of knowing if any given address will work or not.
It's not smart UI design to provide users with a feature that will normally never work, and for which they can't even guess at whether it will.
What would be better to see is a standardized (probably HTTPS based) protocol in which a Bitcoin URI could contain a domain name, and then your client would challenge the domain to sign a nonce with the key corresponding to the address (or raw pubkey). This means in your client the payment can be rendered and recorded as a payment to "foobar.com", which is much more helpful. That protocol could then be extended to support "user@foobar•com" type challenges so when a bitcoin: link is provided, the server is challenged to prove ownership by that user of that public key. It means the details are hidden and when the feature is present, the UI gets silently better, but there's never any demand on any users to do anything different. The "copy Bitcoin address" button in the UI can provide the clipboard with both text/plain and text/html content so the right one is picked depending on context.
I'm offering patches for DNS lookup, which seems good enough to locate the irc server but not good enough for the folks that use copy/paste.
from a usability standpoint, the clipboard isn't a UI element in flow design. Its also subject to MITM attacks for the most popular OSes.
Finally, think beyond you and your friends to how you can buy coffee at starbucks easier and faster than with a starbucks card. Thats how you make successful apps and protocols.
Has anyone offered to write the mythical https-address-resolver-easy-button for bitcoind?
-rick
On Sat, Jul 30, 2011 at 4:34 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (34 lines)
> This was already discussed on the forums, but clear use cases would be helpful. > > I originally thought this feature seemed like a no-brainer, but > randomly emailing money to people out of the blue is not a very common > operation. You almost always have contact with them first, if only to > say "hey, I'm going to send you some money", but more commonly to > figure out how much you're going to pay and what for. > > Once you have communication, providing an address in-band isn't very > hard, and it has the advantage of always working. Doing anything with > DNS or magic HTTPS endpoints means that 90% of the time, your feature > *will not work* (eg it won't work for any gmail/yahoo/hotmail account) > and users will rapidly learn not to bother trying as they have no way > of knowing if any given address will work or not. > > It's not smart UI design to provide users with a feature that will > normally never work, and for which they can't even guess at whether it > will. > > What would be better to see is a standardized (probably HTTPS based) > protocol in which a Bitcoin URI could contain a domain name, and then > your client would challenge the domain to sign a nonce with the key > corresponding to the address (or raw pubkey). This means in your > client the payment can be rendered and recorded as a payment to > "foobar.com", which is much more helpful. That protocol could then be > extended to support "user@foobar•com" type challenges so when a > bitcoin: link is provided, the server is challenged to prove ownership > by that user of that public key. It means the details are hidden and > when the feature is present, the UI gets silently better, but there's > never any demand on any users to do anything different. The "copy > Bitcoin address" button in the UI can provide the clipboard with both > text/plain and text/html content so the right one is picked depending > on context. >
On Sat, 2011-07-30 at 06:42 -0700, Rick Wesson wrote:
Quoted text (2 lines)
> Has anyone offered to write the mythical > https-address-resolver-easy-button for bitcoind?
That was my point, it already has been written...twice IIRC.