Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
[continued] 3 We use a 2 tier lookup format. The first lookup returns a list of currencies or payment types supported by the Wallet Name. The second lookup goes to a record specific to that currency type to get the address to go to. We believe this to be a more scalable solution in a world where someone can have both multiple digital currency types, but then also multiple types of colored coins, and wants a simple way to share a single name for all of those different addresses. This allows the wallet to do the work behind the scene of choosing the currency it wants to send, and automatically getting back the right address to send to, without the user having to do anything different. We do the same thing, except in a single call. Here's an example of a record that has both XMR and BTC addresses: https://api.openalias.org/donate.getmonero.org?view=full (here are the DNS records for that: http://mxtoolbox.com/SuperTool.aspx?action=txt%3adonate.getmonero.orgrun=toolpage ) We looked at doing this in a single lookup as you did. With one or two currencies this can be potentially more efficient. As the number of supported currencies and addresses under a single name grows, however, this solution becomes potentially more problematic. Please follow the use cases below: Use case 1: Wallet Name = bob.foo.bar or OpenAlias = bob.foo.bar The only currency supported is bitcoin, and there are no colored coin formats supported. OpenAlias case: 1 packet lookup to bob.foo.bar 1 packet response with bitcoin address = 2 packets Wallet Name case: 1 packet lookup to _wallet.bob.foo.bar 1 packet response with supported address types 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 4 packets Wallet Name Case 1a: The wallet doing the lookup knows it wants bitcoin, so it skips the supported addresses lookup 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 2 packets In this use case we might create more traffic, but it could also be reduced by doing smart lookups. Use case 2: Wallet Name = bob.foo.bar or OpenAlias = bob.foo.bar Many currencies and colored coin addresses are supported under the same name, lets say 100. When you count different currencies and colored coin types, it could easily be hundreds, or over a thousand. OpenAlias case: 1 packet lookup to bob.foo.bar 100 packet responses with various addresses = 101 packets Wallet Name case: 1 packet lookup to _wallet.bob.foo.bar 1 packet response with supported address types 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 4 packets Wallet Name Case 2a: The wallet doing the lookup knows it wants bitcoin, so it skips the supported addresses lookup 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 2 packets While you may end doing less lookups under Open Alias, as it scales, you end up causing a significant amount of extra, unnecessary traffic. In addition to the obvious impact of being orders of magnitude more wasteful than necessary, it also creates privacy leakage by returning someone 100 different addresses when they only asked for one. Finally, because a single packet UDP transaction for a DNS lookup can create possibly hundreds of packets in response, the service can essentially become an amplifier for DDoS attacks. (If I spoof the source address of my target with a query to a lookup that issues hundreds of packets in response to one packet, and I can have a real impact :( ) 4 We mandate DNSSEC while you make it optional. We did this because we believe giving the user the option of NOT using DNSSEC is like letting them order a car with no brakes. We weren't sure how we would explain to them why their money was gone when they really didn't understand the risks they were taking up front. We had a lot of discussion about it before coming to the decision we did, and I can see why you went the other way, although I do believe we made the right choice. With OpenAlias a DNSSEC fail is a soft fail, and the user has to confirm the address. The reasons are threefold: 1. At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones include some biggies like .sg, .za, and .to I think this is a good point, and one we weighed. When we were making our original decisions. Given the importance of ensuring that the lookups return the correct value, and the known vulnerabilities in DNS without DNSSEC, coupled with the fact that ICANN has mandated all zones and registries move to DNSSEC, our belief was and is that it was worth the trade off that there were cases where existing domains would not work. It is important to note, that ICANN has required for some years that registrars and registries support DNSSEC on the domains they register. I personally believe we shouldn't delay use of DNSSEC until their registries had come up to current required
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
I appreciate the thought :) I think where we differ is on where we believe the trade offs should be on perceived privacy versus censorship resistance and centralization. By having a limited number of proxies people need to go through to easily implement, be it the 4 you recommend, or 53, you actually have a very limited number of actors for an authority or hacker to go to in order to be able to install/force logging, or censorship. This very centralization forces us back to a model where we need to trust a very small number of actors in order for the system to operate as designed. This, to me, appears to be the opposite of the goals of the bitcoin ecosystem. To ensure this point is clear, I strongly believe recommending people focus all lookups through 4 centralized proxies is a bad idea and counter to bitcoin's ideals. The fact that hackers or state actors need to corrupt only a small number of servers/services in order to gain global visibility into all queries, I believe, breaks any perceived privacy gains from using DNSCrypt. A very small number of hacks or subpoenas and everyone's records are fair game in one place. You're misstating (or not understanding) the attack surface. State-level attackers won't compromise 50+ DNSCrypt servers, they can get the information on lookups a lot more trivially. Censorship resistance and protection from state-level attackers comes from the decentralised side of OpenAlias (ie. Namecoin resolution, preferably done using a local copy of the NMC blockchain). Since Netki supports Namecoin resolution too there is no need to worry about protecting end users from that. There is, however, a need to protect users from man-in-the-middle attacks where the data is not modified en-route, but it is sniffed. Who you pay in a financial transaction is, and should be, privileged information between yourself and that person. By encouraging open DNS lookups you're effectively hanging that information out for all to see. It is true that there are only 4 DNSCrypt servers we are comfortable recommending. It is also true that there were, at one stage, only 4 Electrum servers. There were also only 4 Bitcoin nodes. As something grows and becomes more useful and usable the number of voluntary participants becomes much greater, and we will provide the necessary tools to enable these volunteers. So in a world where tens of thousands of Bitcoiners are using an aliasing standard (which, in and of itself, is a convenience service anyway), and hundreds of individuals and companies are hosting DNSCrypt resolvers, is it even a valid argument to harp on the number of proxies? Thus it is not worth talking about today. It is definitely worth discussing in future if the number of DNSCrypt resolvers doesn't increase, but that is a different discussion for a different time. For the highly privacy conscious they can, today do their DNS lookups over a non logging VPN connection without forcing everyone else through a handful of centralized servers. Or they can use DNSCrypt optionally themselves. All of our tools have always been open source and folks can modify them for their own desired uses, or submit pull requests with their own ideas. Everyone should be highly privacy conscious when it comes to financial transactions, and it would be unconscionable of both you and I not to defend end-user privacy. We'd love to hear others thoughts on this. While I believe that for now the centralization trade offs required to use DNSCrypt today (via a limited number of proxies) outweigh any perceived privacy benefits it provides, we are always open to what others in the community believe and have made modifications to how things work before as a result of feedback from industry participants. It's important to remember that the paranoid won't use an aliasing service, or at best will use a local Namecoin blockchain for that purpose. This is a convenience service to provide general and broad appeal for the non-technical, and those are the very people that need to be protected from nosey neighbours / workmates / ISPs. Privacy is not only (or even at all) about protecting people buying drugs on a darknet market, it is about defending personal liberties. I think DANE is a great idea. We were just discussing that with Andreas S., and are currently looking at whether we want to add this as optional versus mandatory, based on how widely available DANE is for folks using services like Cloudflare, Akamai, etc for their DNS, which many providers in the space today are. Of course, the security conscious could setup DANE on the URL we use AS IS. There is no need to create a special kv pair for this as is done in OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box. Embedding the TLSA record in a KV pair just means that pinning takes one less step. The CA validation, in our case, is an ADDITIONAL signature based validation to the DNSSEC chain,
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Thomas, I think this is interesting and has some good thoughts behind it. For clarity, are you recommending that the _oa2 portion of the domain name be hidden as a way to make it easier to delegate just wallet names from a zone? On Thu, Jul 23, 2015 at 6:07 AM, Thomas Voegtlin via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Le 23/07/2015 11:48, Thomas Voegtlin via bitcoin-dev a écrit : One benefit of having an intermediate _wallet level is to allow zone delegation. Is that the reason for that choice? Thinking about it, I think that it would be better to separate those two operations: on one hand, the listing of TXT records under a name, and on the other hand, the possibility to use Zone Delegation. For example, let us use the _oa2 name (Openalias version 2) when we need to introduce an intermediate level, and _oa2_keys for key listing. Here is an example: _oa2_keys.sample 3600 IN TXT btc ltc email fullname _btc.sample 3600 IN TXT bitcoinaddress _ltc.sample 3600 IN TXT litecoinaddress _btc.sample 3600 IN TXT otherbitcoinaddress _email.sample 3600 IN TXT john.sm...@googlemail.com _fullname.sample 3600 IN TXT John Smith Zone Delegation: Let us assume example.com wants to delegate all its Bitcoin aliases to Netki. We introduce an intermediate level, with the _oa2 name. In the alias, this string is translated as @ john._oa2.example.com-- will be looked up as j...@example.com _btc.john._oa2.example.com -- bitcoin address of j...@example.com ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Justin W. Newton Founder/CEO NetKi, Inc. jus...@netki.com +1.818.261.4248 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
There are several reasons why we rejected doing it this way with OpenAlias: 1. It adds complexity for the alias creator. This may seem unimportant, but the OpenAlias standard was created to empower people to create their own aliases as simply as possible, not to make it overly complex. 2. It's harder to mess things up by dropping a sub-record; you either have the complete, valid record, or you don't. With a tiered system you can claim that you support a particular alias, but then lack all or some of the records for it. 3. You retain both forward and backwards compatibility (no need to introduce a new OA version unnecessarily), as you can have an old KV pair and a new KV pair within the same record. The addition of KV pairs doesn't require the application to know the new pairs exist, which makes it more extensible. 4. Even better - since an application gets the whole record it can start off with a minimum viable product that merely gets the address, and then at a later stage when support is added for additional metadata *it already has the metadata* and can interpret it. 5. You can still do DNS delegation (proper, SOA delegation) or you can do delegation via a KV pair of some sort (say, a reroute= pair or something). In both cases delegation requires an additional lookup, so there's nothing saved or improved with the two-tier system. In this instance, as in many others, simplicity trumps complexity, and the bonus is that the simpler solution is more extensible and flexible. Riccardo Thinking about it, I think that it would be better to separate those two operations: on one hand, the listing of TXT records under a name, and on the other hand, the possibility to use Zone Delegation. For example, let us use the _oa2 name (Openalias version 2) when we need to introduce an intermediate level, and _oa2_keys for key listing. Here is an example: _oa2_keys.sample 3600 IN TXT btc ltc email fullname _btc.sample 3600 IN TXT bitcoinaddress _ltc.sample 3600 IN TXT litecoinaddress _btc.sample 3600 IN TXT otherbitcoinaddress _email.sample 3600 IN TXT john.sm...@googlemail.com _fullname.sample 3600 IN TXT John Smith Zone Delegation: Let us assume example.com wants to delegate all its Bitcoin aliases to Netki. We introduce an intermediate level, with the _oa2 name. In the alias, this string is translated as @ john._oa2.example.com-- will be looked up as j...@example.com _btc.john._oa2.example.com -- bitcoin address of j...@example.com ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Le 19/07/2015 01:01, Justin Newton via bitcoin-dev a écrit : I would rather not make Namecoin part of the standard, because .bit records cannot be verified easily by lightweight/spv wallets; they would need a copy of the Namecoin blockchain for that. You are the second person to raise this. Clearly this is an item that requires some discussion before anything is decided for sure. We had gone this direction (and I assume Riccardo did as well) to provide a censor resistant option as well as one that would be low cost for individuals to be able register their own names. This also allows for lookups that never leave the local network. The trade off there for mobile wallets was one I feel we failed to properly consider. I think our common goal should be to standardize DNS records holding Bitcoin addresses, because they are going to be used by both Netki and Electrum. You and Ricardo may find it useful to have other types of lookups, such as Namecoin, and that's fine with me, but I do not want that to slow down or stall the current standardisation effort, because Namecoin lookups are clearly not an option for lightweight wallets. That is what I meant by 'not part of the standard'; let's work on what we have in common :) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
I appreciate the thought :) I think where we differ is on where we believe the trade offs should be on perceived privacy versus censorship resistance and centralization. By having a limited number of proxies people need to go through to easily implement, be it the 4 you recommend, or 53, you actually have a very limited number of actors for an authority or hacker to go to in order to be able to install/force logging, or censorship. This very centralization forces us back to a model where we need to trust a very small number of actors in order for the system to operate as designed. This, to me, appears to be the opposite of the goals of the bitcoin ecosystem. To ensure this point is clear, I strongly believe recommending people focus all lookups through 4 centralized proxies is a bad idea and counter to bitcoin's ideals. The fact that hackers or state actors need to corrupt only a small number of servers/services in order to gain global visibility into all queries, I believe, breaks any perceived privacy gains from using DNSCrypt. A very small number of hacks or subpoenas and everyone's records are fair game in one place. You're misstating (or not understanding) the attack surface. State-level attackers won't compromise 50+ DNSCrypt servers, they can get the information on lookups a lot more trivially. Censorship resistance and protection from state-level attackers comes from the decentralised side of OpenAlias (ie. Namecoin resolution, preferably done using a local copy of the NMC blockchain). Since Netki supports Namecoin resolution too there is no need to worry about protecting end users from that. There is, however, a need to protect users from man-in-the-middle attacks where the data is not modified en-route, but it is sniffed. Who you pay in a financial transaction is, and should be, privileged information between yourself and that person. By encouraging open DNS lookups you're effectively hanging that information out for all to see. It is true that there are only 4 DNSCrypt servers we are comfortable recommending. It is also true that there were, at one stage, only 4 Electrum servers. There were also only 4 Bitcoin nodes. As something grows and becomes more useful and usable the number of voluntary participants becomes much greater, and we will provide the necessary tools to enable these volunteers. So in a world where tens of thousands of Bitcoiners are using an aliasing standard (which, in and of itself, is a convenience service anyway), and hundreds of individuals and companies are hosting DNSCrypt resolvers, is it even a valid argument to harp on the number of proxies? Thus it is not worth talking about today. It is definitely worth discussing in future if the number of DNSCrypt resolvers doesn't increase, but that is a different discussion for a different time. For the highly privacy conscious they can, today do their DNS lookups over a non logging VPN connection without forcing everyone else through a handful of centralized servers. Or they can use DNSCrypt optionally themselves. All of our tools have always been open source and folks can modify them for their own desired uses, or submit pull requests with their own ideas. Everyone should be highly privacy conscious when it comes to financial transactions, and it would be unconscionable of both you and I not to defend end-user privacy. We'd love to hear others thoughts on this. While I believe that for now the centralization trade offs required to use DNSCrypt today (via a limited number of proxies) outweigh any perceived privacy benefits it provides, we are always open to what others in the community believe and have made modifications to how things work before as a result of feedback from industry participants. It's important to remember that the paranoid won't use an aliasing service, or at best will use a local Namecoin blockchain for that purpose. This is a convenience service to provide general and broad appeal for the non-technical, and those are the very people that need to be protected from nosey neighbours / workmates / ISPs. Privacy is not only (or even at all) about protecting people buying drugs on a darknet market, it is about defending personal liberties. I think DANE is a great idea. We were just discussing that with Andreas S., and are currently looking at whether we want to add this as optional versus mandatory, based on how widely available DANE is for folks using services like Cloudflare, Akamai, etc for their DNS, which many providers in the space today are. Of course, the security conscious could setup DANE on the URL we use AS IS. There is no need to create a special kv pair for this as is done in OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box. Embedding the TLSA record in a KV pair just means that pinning takes one less step. The CA validation, in our case, is an ADDITIONAL signature based validation to the DNSSEC chain, not a
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
[CONTINUED] Additionally, we just released another open source API server to help with the other half of the lookup problem. Its in its infancy, and we are certainly taking feedback on it at this time. It is called Addressimo https://github.com/netkicorp/addressimo and will serve unique HD Wallet addresses or Payment Requests for every lookup, thus allowing a user to have a private, secure way to share a Wallet Name that can be used to send them any digital currency. Oh snap...https://github.com/openalias/openalias-api These are actually vastly different pieces of software, at least from the description, and a first read of the code. My understanding is the software you linked to here basically takes the DNS work out of lookups for people, as we released: https://github.com/netkicorp/wns-api-server Its our Wallet Name Lookup server. Addressimo, as I described above, provides a different purpose. Its a way for service providers, mobile wallet providers or end users to have an online server that can serve unique wallet addresses ala HD Wallets (BIP32) or signed Payment Requests (BIP0070). This allows for an easy way to increase security and privacy by serving a unique address for every request, and/or sign the address (and other optional data) with an X509 private key to prove ownership of the address in a way independent of and supplemental to the DNSSEC chain (also can be DANE for yet another layer of security). It also supports offline signing of the Payment Requests so the server doesn't have to have access to a private key, or need to be trusted. In any case, I'd much rather we had one effort going forward than multiples, so let's talk! I agree, and you guys are in an ideal position to change to supporting the OpenAlias standard (and enhancing it) without skipping a beat. We would definitely appreciate and take your input and efforts, and that would make OpenAlias v2 (oa2:) a standard built out in conjunction with Netki. Not only do you get Electrum support without lifting a finger, but it will go a long way to repairing your relationship with the open-source community at large, several proponents of which have taken great umbrage at what you were previously pushing as a closed-source, centralised system. I'm a little confused by these closing statements. Our system has, from the beginning been open in terms of the fact that anyone could both serve names or do lookups without ever touching our servers, talking to us, or us even knowing that they did it or that they even exist. Our system has NEVER been one where folks were required to use us for any portion of the service, and from our first beta product launch our open source tools did all lookups against DNS records and the blockchain, never any proprietary servers or interfaces on our side. In terms of the format itself being open, we have already made several extensions and modifications to it as a result of conversations with industry participants in order to ensure that what we are building meets the needs of the community at large. We will gladly continue to do so, it is how we ensure we are building something everyone needs! I'd love to know where you got information that we were in some way a closed and centralized system so that we can have an opportunity to clarify that misconception. In terms of finding a common standard, as I said, I am thrilled to have the conversations, but there are some places, highlighted above, that would cause me to hesitate to just implement the Open Alias standard. I can also see places where bringing the formats together to one standard could have strong benefits, for example: I think formatting the record as a key value pair with versioning has merit, and would love to move it in to what we are doing (and likely will). On the other side, I think the two level lookup provides a lot of value at scale over trying to send back a bunch of text records when only a small portion of the data is used. I'd love to hear thoughts from others in the community on mandating DNSSEC and thoughts on DNSCrypt. I have a strong opinion on both of those but would love to engage in thoughtful dialogue around what path best suits the need of the community. Looking forward to the discussion! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
[continued] 3 We use a 2 tier lookup format. The first lookup returns a list of currencies or payment types supported by the Wallet Name. The second lookup goes to a record specific to that currency type to get the address to go to. We believe this to be a more scalable solution in a world where someone can have both multiple digital currency types, but then also multiple types of colored coins, and wants a simple way to share a single name for all of those different addresses. This allows the wallet to do the work behind the scene of choosing the currency it wants to send, and automatically getting back the right address to send to, without the user having to do anything different. We do the same thing, except in a single call. Here's an example of a record that has both XMR and BTC addresses: https://api.openalias.org/donate.getmonero.org?view=full (here are the DNS records for that: http://mxtoolbox.com/SuperTool.aspx?action=txt%3adonate.getmonero.orgrun=toolpage ) We looked at doing this in a single lookup as you did. With one or two currencies this can be potentially more efficient. As the number of supported currencies and addresses under a single name grows, however, this solution becomes potentially more problematic. Please follow the use cases below: Use case 1: Wallet Name = bob.foo.bar or OpenAlias = bob.foo.bar The only currency supported is bitcoin, and there are no colored coin formats supported. OpenAlias case: 1 packet lookup to bob.foo.bar 1 packet response with bitcoin address = 2 packets Wallet Name case: 1 packet lookup to _wallet.bob.foo.bar 1 packet response with supported address types 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 4 packets Wallet Name Case 1a: The wallet doing the lookup knows it wants bitcoin, so it skips the supported addresses lookup 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 2 packets In this use case we might create more traffic, but it could also be reduced by doing smart lookups. Use case 2: Wallet Name = bob.foo.bar or OpenAlias = bob.foo.bar Many currencies and colored coin addresses are supported under the same name, lets say 100. When you count different currencies and colored coin types, it could easily be hundreds, or over a thousand. OpenAlias case: 1 packet lookup to bob.foo.bar 100 packet responses with various addresses = 101 packets Wallet Name case: 1 packet lookup to _wallet.bob.foo.bar 1 packet response with supported address types 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 4 packets Wallet Name Case 2a: The wallet doing the lookup knows it wants bitcoin, so it skips the supported addresses lookup 1 packet lookup to _btc._wallet.bob.foo.bar 1 packet response with bitcoin address = 2 packets While you may end doing less lookups under Open Alias, as it scales, you end up causing a significant amount of extra, unnecessary traffic. In addition to the obvious impact of being orders of magnitude more wasteful than necessary, it also creates privacy leakage by returning someone 100 different addresses when they only asked for one. Finally, because a single packet UDP transaction for a DNS lookup can create possibly hundreds of packets in response, the service can essentially become an amplifier for DDoS attacks. (If I spoof the source address of my target with a query to a lookup that issues hundreds of packets in response to one packet, and I can have a real impact :( ) 4 We mandate DNSSEC while you make it optional. We did this because we believe giving the user the option of NOT using DNSSEC is like letting them order a car with no brakes. We weren't sure how we would explain to them why their money was gone when they really didn't understand the risks they were taking up front. We had a lot of discussion about it before coming to the decision we did, and I can see why you went the other way, although I do believe we made the right choice. With OpenAlias a DNSSEC fail is a soft fail, and the user has to confirm the address. The reasons are threefold: 1. At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones include some biggies like .sg, .za, and .to I think this is a good point, and one we weighed. When we were making our original decisions. Given the importance of ensuring that the lookups return the correct value, and the known vulnerabilities in DNS without DNSSEC, coupled with the fact that ICANN has mandated all zones and registries move to DNSSEC, our belief was and is that it was worth the trade off that there were cases where existing domains would not work. It is important to note, that ICANN has required for some years that registrars and registries support DNSSEC on the domains they register. I personally believe we shouldn't delay use of DNSSEC until their registries had come up to current required
