Re: [Bitcoin-development] bitcoin DNS addresses

Re: [Bitcoin-development] bitcoin DNS addresses

[phantomcircuit]

dns resolution is far simpler to implement than properly checking the https certificate chain

Matt Corallo <bitcoin-list@bluematt.me> wrote:

>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

Re: [Bitcoin-development] bitcoin DNS addresses

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

On Sat, 2011-07-30 at 06:42 -0700, Rick Wesson wrote:
> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] bitcoin DNS addresses

[Rick Wesson]

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:
> 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.
>

Re: [Bitcoin-development] bitcoin DNS addresses

[Mike Hearn]

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.

Re: [Bitcoin-development] bitcoin DNS addresses

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

On Tue, 2011-07-26 at 09:50 -0700, Rick Wesson wrote:
> [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.
> 
> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] bitcoin DNS addresses

[Rick Wesson]

[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

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

Re: [Bitcoin-development] bitcoin DNS addresses

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] bitcoin DNS addresses

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

On Mon, 2011-07-25 at 20:35 -0700, Rick Wesson wrote:
> 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).
> 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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] bitcoin DNS addresses

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 440 bytes --]

Re: [Bitcoin-development] bitcoin DNS addresses

[Luke-Jr]

On Tuesday, July 26, 2011 12:54:23 AM Rick Wesson wrote:
> > 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.

> > 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

> > 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.

Re: [Bitcoin-development] bitcoin DNS addresses

[Rick Wesson]

>
> 1. Right now you practically need a unique Bitcoin address per transaction.

I'd like to find ways to alievate this requirement.

> 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.

> 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

> 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. ;)
>

Re: [Bitcoin-development] bitcoin DNS addresses

[Luke-Jr]

On Monday, July 25, 2011 11:35:34 PM Rick Wesson wrote:
> 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. ;)

Re: [Bitcoin-development] bitcoin DNS addresses

[Rick Wesson]

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:
> 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
>
>

Re: [Bitcoin-development] bitcoin DNS addresses

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[Bitcoin-development] bitcoin DNS addresses

[Rick Wesson]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

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]);
...

[-- Attachment #2: Type: text/html, Size: 2572 bytes --]