Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Justin Newton via bitcoin-dev]

[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.org&run=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 s

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Riccardo Spagni via bitcoin-dev]

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

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin via bitcoin-dev]

Le 27/07/2015 23:51, Justin Newton via bitcoin-dev a écrit :
> 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?
> 

I don't think you can completely "hide" it, because you need to know
where the _oa2 is in the name, in order to perform requests. In my
proposal it was denoted by a @ character in the alias:

x@y.z -> x._oa2.y.w

___
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

[Riccardo Spagni via bitcoin-dev]

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

[Justin Newton via bitcoin-dev]

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

[Thomas Voegtlin via bitcoin-dev]

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

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin via bitcoin-dev]

Le 17/07/2015 03:01, Justin Newton via bitcoin-dev a écrit :
>> 3> We use a 2 tier lookup format. [...]
>>
>> We do the same thing, except in a single call. [...]
> 
> 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. [...]

Hi Justin,

Your lookup solution is indeed more efficient than OpenAlias, and more
robust to DoS. However, that is not because you use a two-tier lookup.

Indeed, instead of having the following records:
_wallet.sample = "btc ltc"
_btc._wallet.sample = "mybitcoinadress"

you could simply have:
_wallet.sample = "btc ltc"
_btc.sample = "mybitcoinaddress"

In practice, a wallet supporting only Bitcoin will skip the currencies
lookup in both cases, and go directly for the _btc record.

One benefit of having an intermediate "_wallet" level is to allow zone
delegation. Is that the reason for that choice?

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

[Mike Hearn via bitcoin-dev]

>
> What do you mean by "under some new roots" ?
>

I mean, most users will need to sign up for some new identity under a DNS
tree that they don't currently use (whether that's netki.com or whatever).
___
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

[Thomas Voegtlin via bitcoin-dev]

Le 20/07/2015 17:14, Mike Hearn a écrit :
> 
> By "alias" you mean domain name? I'm not sure what DNS key means in this
> context.
> 

yes, sorry, I mean the domain name corresponding to the TXT record.
it's called 'alias' in the context of OpenAlias.


> I'm still not really convinced that a domain name under some new roots is
> an identity people will want to use, but yes, I guess your approach would
> work for those who do want it.

What do you mean by "under some new roots" ?

If I believe Netki, there is enough people who want to have a Bitcoin
address stored in DNS, for at least one company to thrive. :)

All I am proposing is a new usage for these already existing DNS
records; not only to receive BTC, but also to sign requests with them.

> It still may be worth exploring the compact cert+optimized BIP70 (no
> DNSSEC) in a qrcode if making a network that stores small bits of data
> really is beyond us :(
> 
Heh, pastebin + base64 encoding the PR could work. However, it might
violate their ToS. More seriously, there might be some legal issues for
a company willing to provide that kind of service.

Re QR codes: 150 bytes, using base43 encoding, is not too bad.
___
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

[Mike Hearn via bitcoin-dev]

>
> The final signature is a signature of the payment request, it is not
> part of DNSSEC. So, yes, that signature can be EC.
>

Right, got it. I think we've been talking about two related but separate
issues (DNSSEC vs squeezing payment requests into URIs/qrcodes somehow).
So: DNSSEC attests via an RSA chain to some EC key stored in the wallet
which is then used to sign the payment request or URI, which also contains
a domain name.


> The payment requests I am currently playing with have the following values:
>
> pki_type = "dnssec+btc" (btc means that the signature is checked against
> a Bitcoin address stored in DNS)
> pki_data = the user's alias (DNS key)


By "alias" you mean domain name? I'm not sure what DNS key means in this
context.

I'm still not really convinced that a domain name under some new roots is
an identity people will want to use, but yes, I guess your approach would
work for those who do want it.

It still may be worth exploring the compact cert+optimized BIP70 (no
DNSSEC) in a qrcode if making a network that stores small bits of data
really is beyond us :(
___
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

[Thomas Voegtlin via bitcoin-dev]

Le 20/07/2015 16:42, Mike Hearn a écrit :
>>
>> In my previous post, I was suggesting to *not* include the proof in the
>> request, because the payer can download it independently. Only the final
>> signature is needed. What makes DNSSEC interesting is not the size of
>> the proof, but rather the fact that you can request it easily, and in a
>> canonical way.
>>
> 
> Yes, but you still need the final signature. Is it possible to use an EC
> signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
> about that, and all you need is 32 bytes, then my argument does not hold.
> 

The final signature is a signature of the payment request, it is not
part of DNSSEC. So, yes, that signature can be EC.

The DNSSEC proof is used to verify that the public key, which is
recovered from the signature, corresponds to the alias.

The payment requests I am currently playing with have the following values:

pki_type = "dnssec+btc" (btc means that the signature is checked against
a Bitcoin address stored in DNS)
pki_data = the user's alias (DNS key)

___
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

[Mike Hearn via bitcoin-dev]

>
> In my previous post, I was suggesting to *not* include the proof in the
> request, because the payer can download it independently. Only the final
> signature is needed. What makes DNSSEC interesting is not the size of
> the proof, but rather the fact that you can request it easily, and in a
> canonical way.
>

Yes, but you still need the final signature. Is it possible to use an EC
signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
about that, and all you need is 32 bytes, then my argument does not hold.
___
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

[Thomas Voegtlin via bitcoin-dev]

hi Mike,

I hope you had a good trip!


> To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
> 
>1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
>won't fit nicely in a QR code, I think.
> 
>2. 1024 bit is the absolute minimum strength you can get away with,
>really. DNSSEC assumes frequent key rotations to try and help, which
>complicates things.
> 
> So I'm not sure using DNSSEC fixes the usability problem we want to fix.
> 

In my previous post, I was suggesting to *not* include the proof in the
request, because the payer can download it independently. Only the final
signature is needed. What makes DNSSEC interesting is not the size of
the proof, but rather the fact that you can request it easily, and in a
canonical way.

A typical lightweight payment request, serialized with EC signature and
without the proof, would be about 150 bytes long.


> I will do a separate reply to break out some thoughts on replacing QR codes.
> 
> Would it be possible to create the same kind of "lightweight payment
>> requests" using SSL certificates? Probably, if the final signing key is
>> a EC key, and if the payment request does not include the whole chain of
>> certificates.
> 
> 
> Given that the pre-existing value of the PKI is much lower for individuals
> than for companies/websites, where they all have certs already, building a
> Bitcoin-specific or entirely new/independent PKI for people is not so
> unthinkable, I agree.
> 
> In theory such a cert could be as minimal as:
> 
> thom...@electrum.org
> 
> so literally just a signature + a UTF-8 string, and that's it! You don't
> need anything more if you're willing to sacrifice extensibility,
> revocability, etc.

Again, we don't have to sacrifice revocability, if the proof is
downloaded separately.

> 
> The pubkey of the CA would be obtained by running the pubkey recovery
> algorithm on the signature, and then checked against a table of trusted
> pubkeys.
> 
___
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

[Mike Hearn via bitcoin-dev]

Hey Thomas,

Was great to hang out with you in Berlin last week!


> Bitcoin addresses do not require a webserver. If we want to build
> something that competes with that, we should have at least that level of
> convenience.
>

Absolutely agree! Convenience for the user is an absolute must. I just
don't know how to let users exchange large data packets without some kind
of server acting as a dropbox in the middle. That leaves two solutions:

1) Set up a way for users to exchange large data packets by using other
people's web servers, e.g. with no user visible signup flow (pure p2p/done
automatically in the background by user wallets)

2) Make the data packets small instead.

We can debate better signing methods that work towards (2). The reason I am
unsure about this is that the point of BIP70 is to be extended with useful
features. Even if we find a way to squeeze a human-meaningful
signature/cert into a URI, that's only one of BIP70s features. The next set
we want to add might end up running out of space again.

A lot of the problems come from how limited QR codes are. So perhaps there
is also a third approach: either find a better replacement for QR codes
(maybe something that uses colour like Microsoft Tag
), or drop them as a design
constraint.

Calling Jeff Garzik, Jeff, are you there? I recall BitPay did some
experiments to find out how much data you can stuff into a QR code before
it hurts scannability too much, do you have a writeup anywhere?

This is the main reason I feel uneasy about anything that isn't "build a
store+forward network". QR codes are so fundamental to our ecosystem, but
sooo limited, that I'm not sure how else to move forward. We were told
when designing BIP70 that even putting a URL in the QR code is pushing it!
There was talk of compressing the URL in some way. So adding even an ECC
signature which is much longer seems risky.

We can imagine a parallel universe where our societies technology was more
NFC oriented: laptops had NFC tags in them, phones had better NFC support
etc. Then we would have more bytes to play with and we wouldn't face this
pointer-indirection problem :( But laptops don't have the hardware and
Apple sits on their NFC API because they can't imagine any use case that
isn't credit cards :( :(

To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:

   1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
   won't fit nicely in a QR code, I think.

   2. 1024 bit is the absolute minimum strength you can get away with,
   really. DNSSEC assumes frequent key rotations to try and help, which
   complicates things.

So I'm not sure using DNSSEC fixes the usability problem we want to fix.

I will do a separate reply to break out some thoughts on replacing QR codes.

Would it be possible to create the same kind of "lightweight payment
> requests" using SSL certificates? Probably, if the final signing key is
> a EC key, and if the payment request does not include the whole chain of
> certificates.


Given that the pre-existing value of the PKI is much lower for individuals
than for companies/websites, where they all have certs already, building a
Bitcoin-specific or entirely new/independent PKI for people is not so
unthinkable, I agree.

In theory such a cert could be as minimal as:

thom...@electrum.org

so literally just a signature + a UTF-8 string, and that's it! You don't
need anything more if you're willing to sacrifice extensibility,
revocability, etc.

The pubkey of the CA would be obtained by running the pubkey recovery
algorithm on the signature, and then checked against a table of trusted
pubkeys.
___
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

[Thomas Voegtlin via bitcoin-dev]

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

[Thomas Voegtlin via bitcoin-dev]

Hi Mike,

The reason why I would like to extend BIP70 is because it is currently
not being used in transactions between end-users. BIP70 works very well
in B2C situations, where users buy products from a website. However,
end-users still share Bitcoin addresses.

Before BIP70 was written, I had proposed "Signed URIs", where the
signature is a public proof that a payee requested a payment. This is
one of the main benefits of BIP70, and I still want to bring it to
user-to-user transactions.

I believe one of the main barriers to BIP70 adoption is that bitcoin:
URIs have been extended in a way that requires the request to be hosted
on a webserver. You may complain about the lack of store-and-forward
network, despite the apparent simplicity of creating one such network.
However, that does not mean we should absolutely do things that way and
wait until such a network exists.

Bitcoin addresses do not require a webserver. If we want to build
something that competes with that, we should have at least that level of
convenience.

EC signatures are short, and they can be shared by copy-paste, or added
to a bitcoin: URI. This is a features of my "Signed URIs" proposal, that
was lost in BIP70. Indeed, signed URIs were self-contained. A serialized
payment request can also be made very short, if it is signed by a EC
key, and if it does not include the chain of certificates. Such a
"lightweight request" can be base58-encoded, and easily shared by
copy-paste, or passed in a bitcoin: URI.

Size is another reason why I proposed to use DNSSEC in BIP70 (the first
reason is that the subdomain is signed by the domain, not by an external
CA). Indeed, DNSSEC provides a canonical way to download the chain of
signatures needed to verify a record. Thus, the chain of signatures does
not need to be included in the payment request; it can be downloaded and
archived by the verifier.

Now, I understand that SSL vertificates have distinct advantages over
DNSSEC; for example, CA-signed SSL certificates have a legal value,
which is important for dispute resolution.

Would it be possible to create the same kind of "lightweight payment
requests" using SSL certificates? Probably, if the final signing key is
a EC key, and if the payment request does not include the whole chain of
certificates. (However, that would require an additional infrastructure
to publish the chain of certificates, and I do not think that x509
certification path are unique, which makes things more complicated, but
not impossible).

Sorry if I did not answer point-by-point to your post. I felt that I
failed to explain one of the reasons why I want to use DNSSEC in the
validation of payment requests.

Thomas




Le 14/07/2015 13:45, Mike Hearn a écrit :
> Hi Thomas,
> 
> Re: NetKi, I think any proposal in this space has to be an open standard,
> almost by the definition of what it is. At any rate, it may be worth
> talking to them. They have signed up to implement their system at least.
> 
> I did understand that your proposal does not rely on email - for instance a
> web forum could issue usern...@reddit.com type aliases, even if those are
> not also email accounts. I am just continuing the comparison against email
> address certs.
> 
> It's also the case that a domain can use the DKIM setup without actually
> offering email accounts. They can just have a web form or API that triggers
> sending of the signed email (or simply, providing the signed headers
> themselves). Thus the same system can be used transparently by both email
> providers and other sites that don't give their users email addresses, but
> would still like to use the same system.
> 
> Hardly anyone uses email certificates today, so I don't think it would
>> affect a lot of users.
> 
> 
> No, but obviously we'd like to change that! The holdup is not the
> certificate side of things, really, but rather the lack of a
> store-and-forward network for signed payment requests. I keep asking
> someone to build one but I fear the problem is almost too simple ..
> everyone who looks at this decides to solve 12 other problems
> simultaneously, it gets complicated, then they never launch :(
> 
> Once there's a simple and robust way to get PaymentRequest's from one end
> user to another, even when that first user is offline, then getting an
> email cert issued is no big deal.
> 
> That does not look so... not until (1) BIP70 wallets integrate with
>> https://crt.sh, (2) you convince that service to index email certs (3)
>> you convince all CAs to report all email certs they issue to crt.sh.
>>
> 
> Any solution that separates identity providers from certificate issuers
> would have these requirements, though. And as many identity providers today
> do not wish to become CAs too, it seems fundamental.
> 
> I don't think it's such a problem, mind you. The crt.sh website is actually
> a frontend to the CT protocol, which is a somewhat blockchain like audit
> log that's eventually intended to contain all issued certific

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Justin Newton via bitcoin-dev]

On Sat, Jul 18, 2015 at 6:29 AM, Thomas Voegtlin via bitcoin-dev
 wrote:
>
> Le 14/07/2015 19:29, Justin Newton a écrit :
>

>
> Sorry to answer late, and thanks for the clarification. After talking
> with you, I believe that it will not be difficult to agree on a common
> standard, that gives maximum freedom to everyone.

100% agreed.

>
> I also believe that it is in Netki's interest to convey the message that
> they are actively promoting an open standard, and not pushing a private
> solution. For this reason, and assuming that the future standard
> satisfies you fully, will you mind if that standard carries a neutral
> name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
> your company? I reckon that is purely a PR issue.

To be clear, the current name of the service is Wallet Name Service,
Netki has tended to be tagged to it as people are associating the
service with us.  We also intend to offer more services than just
this, so its actually not really good for us to think of Netki as the
service name.  I have no issues with a neutral name for the lookup
standard.


>
>
> > To break it down briefly, we have an open lookup standard based on
> > both the namecoin blockchain as well as traditional DNSSEC.  (You can
> > choose your own adventure of using namecoin based names or traditional
> > ICANN names).
>
> 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.



>
> > 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.
> >
>
> This seems to be a major difference, and I believe it makes sense to do
> it the way you describe. Does that solution fully replace the tags used
> in OpenAlias, or does it make sense to combine these two systems?

I think combining formats to use both the two level lookups and tags
could have value.  Tags could include information like versioning, as
well as whether what is being returned is an address, URL for further
lookup, or other piece of information.





>
> > I'd love to talk here or offline about merging standards going
> > forward.  As an FYI, Verisign has also delivered a standard to the
> > IETF using DNSSEC to pass payment information here:
> > https://tools.ietf.org/html/draft-wiley-paymentassoc-00  We have
> > started discussions with them about merging standards as well.
> >
>
> That is nice, but may be out of scope here. Isn't there a risk that
> involving the IETF would make the process a lot slower? Of course it
> would be great, but maybe we should try to reach consensus at our level
> first (the bitcoin level), before trying to merge with them.

I concur with this approach.  I think it makes sense for us to stay in
contact and communication with the IETF side with the hope of ending
up with something that is, in the end the same, or at least
compatible.  I also agree that we shouldn't wait on the IETF to move
ahead ourselves, more stay in communication with them so that we don't
end up accidentally going in opposite directions, and also so we can
learn best practices from each other along the way.

As you can see, this has been our approach up until now where we have
gone ahead and built and expanded our "standard" based on our
discussions and integrations with other industry participants.

Thanks for the feedback!

Justin




-- 

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

[Thomas Voegtlin via bitcoin-dev]

Le 14/07/2015 19:29, Justin Newton a écrit :

> Hi there.  You are correct that we are a company providing a service,
> however, that service is also based on an open standard which we are
> proposing.  I'll be honest that we haven't done the greatest job in
> promoting the standard so far.  More coming soon on that front.  Any
> of the Open Source Wallet Name resolvers that we have created do
> lookups against the standard record formats, and not directly against
> our servers in any way.  Information on the record formats as well as
> links to the lookup API server and some early libraries can be found
> here:  https://www.netki.com/#/developers and here:
> https://github.com/netkicorp
> 

Sorry to answer late, and thanks for the clarification. After talking
with you, I believe that it will not be difficult to agree on a common
standard, that gives maximum freedom to everyone.

I also believe that it is in Netki's interest to convey the message that
they are actively promoting an open standard, and not pushing a private
solution. For this reason, and assuming that the future standard
satisfies you fully, will you mind if that standard carries a neutral
name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
your company? I reckon that is purely a PR issue.


> To break it down briefly, we have an open lookup standard based on
> both the namecoin blockchain as well as traditional DNSSEC.  (You can
> choose your own adventure of using namecoin based names or traditional
> ICANN names).

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.

> Differences:
> 
> 1> We do not use DNSCrypt.  I understand why you chose to, but we were
> concerned about broad interoperability and easy broad distribution of
> hosting, so decided not to use it.  We have other ways of achieving
> privacy, using HD Wallets and Payment Requests.
> 

As far as Electrum is concerned, I do not see DNSCrypt as something
usable in the short term. I do not think it should be mandated, because
there are other ways of achieving privacy, as you say.

> 2> We have the option of storing a URL rather than just a wallet
> address in the TXT record.  This allows a second level lookup against
> the URL to get back a unique HD Wallet address or Payment Request each
> time, further protecting user privacy and security.  Using Wallet
> Names with Payment Requests allows for the user experience of typing
> in an easy to remember name and getting back the "green lock" and who
> the validated recipient is.  This also provides an auto audit of the
> end to end DNS SEC process, in the case the path were somehow
> compromised, the signature on the payment request can provide an
> additional check.
> 

I see value in the ability to store differerent types of strings in TXT
records. In particular, I have the need to store an email address, and
more than one Bitcoin address or xpubkey per alias.

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

This seems to be a major difference, and I believe it makes sense to do
it the way you describe. Does that solution fully replace the tags used
in OpenAlias, or does it make sense to combine these two systems?


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

I agree on this; there is no point using OpenAlias without DNSSEC.
Wallets can use fallback servers if the default DNS does not have DNSSEC.

> 
> 
> 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  and will serve
> unique HD Wallet addresses or Payment Requests for every lookup, thus
> allowing a user to have 

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Mike Hearn via bitcoin-dev]

>
> Agreed, although I guess the bootstrap time for that is a little on
> the high side, and maybe a little too chunky on mobile devices


With warm Tor directory caches it's surprisingly fast - fast enough to be
usable and I'm a notorious stickler for low latency UX. If you want to do
LOTS of lookups so you can cross-check and merge their answers, that's
slower of course.

With cold Tor caches it's indeed too slow. However, reaching "tor by
default" is a part time hobby of the bitcoinj project for a while now and
there are plenty of ideas for how to make things fast enough. For instance,
using a cold cache whilst simultaneously refreshing it in the background,
doing nightly refreshes when charging, lengthening the expiry time, and the
Tor guys I believe want to implement directory differentials too which
would also help.



> My current thinking with Electrum (that ThomasV and I have bounced
> around) is to make the default policy DNSCrypt -> fallback to
> OpenAlias API pool (which can return DNSSEC data for verification) ->
> fallback to default resolver.


That seems reasonable for Electrum. I don't strongly care about these
protocols myself (and Justin knows this already), but whatever is decided
should give maximum freedom to wallet developers who disagree with you and
wish to explore other tradeoffs.
___
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

[Riccardo Spagni via bitcoin-dev]

> It is worth noting that DNS lookups can be done via Tor. In effect that
> gives you 1000+ proxies instead of 56 or 4. BitcoinJ already has code that
> can do this.

Agreed, although I guess the bootstrap time for that is a little on
the high side, and maybe a little too chunky on mobile devices, but
it's absolutely worthwhile as an option. DNSSEC is great because it
doesn't allow resolvers to lie, they can't even pretend that a record
doesn't exist.

> I would agree that it makes sense for proxying of DNS requests to be an
> optional part of the protocol. Wallet developers can then compete on privacy
> vs robustness vs whatever other issues there may be.

My current thinking with Electrum (that ThomasV and I have bounced
around) is to make the default policy DNSCrypt -> fallback to
OpenAlias API pool (which can return DNSSEC data for verification) ->
fallback to default resolver. Turning off DNSCrypt will then make it
default resolver -> fallback to OpenAlias API pool. Turning off the
API pool will make it default resolver or fail. Default resolver can
be set to OS resolver (default) or custom resolvers (eg. Google Public
DNS).

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

[Mike Hearn via bitcoin-dev]

It is worth noting that DNS lookups can be done via Tor. In effect that
gives you 1000+ proxies instead of 56 or 4. BitcoinJ already has code that
can do this.

I would agree that it makes sense for proxying of DNS requests to be an
optional part of the protocol. Wallet developers can then compete on
privacy vs robustness vs whatever other issues there may be.
___
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

[Riccardo Spagni via bitcoin-dev]

> 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

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Justin Newton via bitcoin-dev]

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

[Justin Newton via bitcoin-dev]

[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.org&run=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 s

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Justin Newton via bitcoin-dev]

I am breaking this into a couple of pieces as my first response has been in
a moderator queue for some time because it is too long.


TL;DR version - Wallet Name Service has always been a decentralized and
distributed service that it no way requires you to ever touch the Netki
infrastructure.  We want to work with the community, as we have been from
the beginning, to come up with the best standard possible.

Longer answers inline below.



On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spagni  wrote:

>
>
>> In terms of comparisons to OpenAlias, I think there are a lot of
>> similarities, but a few differences.  First the similarities:
>>
>>
>> 1> We both use DNSSEC.
>>
>> 2> We both have the option of storing the address directly in the DNS
>> record.
>>
>>
>> Differences:
>>
>> 1> We do not use DNSCrypt.  I understand why you chose to, but we were
>> concerned about broad interoperability and easy broad distribution of
>> hosting, so decided not to use it.  We have other ways of achieving
>> privacy, using HD Wallets and Payment Requests.
>>
>
> And this is the part where you guys look really, really incompetent (and I
> don't mean that in a terribly demeaning way, it's just that you're in a
> space where you want to be a domain expert, not make a series of
> embarrassing and public faux pas).
>
>
> 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.


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.

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.






>
>
>> 2> We have the option of storing a URL rather than just a wallet
>> address in the TXT record.  This allows a second level lookup against
>> the URL to get back a unique HD Wallet address or Payment Request each
>> time, further protecting user privacy and security.  Using Wallet
>> Names with Payment Requests allows for the user experience of typing
>> in an easy to remember name and getting back the "green lock" and who
>> the validated recipient is.  This also provides an auto audit of the
>> end to end DNS SEC process, in the case the path were somehow
>> compromised, the signature on the payment request can provide an
>> additional check.
>>
>
> OpenAlias supports this as well, except it does it better by allowing the
> KV pairs to also contain a TLSA record before the request, which
> effectively makes it a DANE-secured interaction. Your interaction requires
> the trusting of multiple CAs, which is an inherent weakness.
>

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.

The CA validation, in our case, is an ADDITIONAL signature based validation
to the DNSSEC chain, not a replacement for it.


 [CONTINUED]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfound

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Riccardo Spagni]

> To break it down briefly, we have an open lookup standard based on
> both the namecoin blockchain as well as traditional DNSSEC.  (You can
> choose your own adventure of using namecoin based names or traditional
> ICANN names).


Good, that's roughly analogous with what OpenAlias defines.

We DO provide a service where we will register or host
> names on your behalf. However if you follow the format and host them
> yourself, everything will work just fine, and our open source lookup
> server and libraries will provide those results exactly the same as if
> the names were hosted with us.


Also good, much the same as https://cryptoname.co and https://xmr.link


> To that end, we have had conversations
> with several companies in the space who intend to host their own
> names, and we intend to work with them on the effort to ensure our
> documentation is sufficient to ensure they can successfully do so.
>
> In terms of comparisons to OpenAlias, I think there are a lot of
> similarities, but a few differences.  First the similarities:
>
>
> 1> We both use DNSSEC.
>
> 2> We both have the option of storing the address directly in the DNS
> record.
>
>
> Differences:
>
> 1> We do not use DNSCrypt.  I understand why you chose to, but we were
> concerned about broad interoperability and easy broad distribution of
> hosting, so decided not to use it.  We have other ways of achieving
> privacy, using HD Wallets and Payment Requests.
>

And this is the part where you guys look really, really incompetent (and I
don't mean that in a terribly demeaning way, it's just that you're in a
space where you want to be a domain expert, not make a series of
embarrassing and public faux pas).

DNSCrypt requires NO work on the part of the alias creator, DNS server,
SOA, or anything else. It is entirely client side, and allows for *private
lookups*. HD Wallets and Payment Requests are inconsequential, an ISP still
knows every DNS resolution their users are performing.

When using dnscrypt-proxy to perform private lookups they are done against
the 55 free and public DNSCrypt resolvers [1], provided by oVPN, OpenNIC,
OpenDNS, okTurtles, CloudNS, and various individuals. OpenAlias links to
and recommends four of these specifically, as they have the unique
combination of providing Namecoin lookups, supporting DNSSEC validation for
lightweight verification, and claiming not to store logs.

Therefore, DNSCrypt provides encrypted, private, secure, end-user lookups
with no implication on the creation side. That you are unaware of this
(when presumably you at least read the Wikipedia article on the topic) and
are not embracing it is quite surprising, to say the least.


> 2> We have the option of storing a URL rather than just a wallet
> address in the TXT record.  This allows a second level lookup against
> the URL to get back a unique HD Wallet address or Payment Request each
> time, further protecting user privacy and security.  Using Wallet
> Names with Payment Requests allows for the user experience of typing
> in an easy to remember name and getting back the "green lock" and who
> the validated recipient is.  This also provides an auto audit of the
> end to end DNS SEC process, in the case the path were somehow
> compromised, the signature on the payment request can provide an
> additional check.
>

OpenAlias supports this as well, except it does it better by allowing the
KV pairs to also contain a TLSA record before the request, which
effectively makes it a DANE-secured interaction. Your interaction requires
the trusting of multiple CAs, which is an inherent weakness.

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.org&run=toolpage
)


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

[bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Justin Newton]

[Sorry to break list threading, I joined the list to respond here, and
don't have the original message to respond to]

[Copying message 9412 from thom...@electrum.org]

Mike Hearn wrote:

>* Hi Thomas,
*> >* FYI there is a company called Netki is also working on a kind of DNSSEC
*>* integration with BIP70,
*>* there's a thread here about their efforts:
*>* 
https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J

*
Hi Mike,

Thanks! I believe it is better to keep the current discussion on
bitcoin-dev, though.

>* If you would like to work on this, perhaps it's worth teaming up with them?
*>* Obviously they plan to have an open spec and open source implementation.
*>
I would love to work with Netki. However, it's not clear to me what they
are selling. OpenAlias is an open standard, not a company. In contrast,
Netki have very long Terms of Service, that do not help understand what
part of their solution is open-source, and what is the product. They
surely know about OpenAlias, it would be nice to hear what they think
about it.

[FROM JUSTIN]


Hi there.  You are correct that we are a company providing a service,
however, that service is also based on an open standard which we are
proposing.  I'll be honest that we haven't done the greatest job in
promoting the standard so far.  More coming soon on that front.  Any
of the Open Source Wallet Name resolvers that we have created do
lookups against the standard record formats, and not directly against
our servers in any way.  Information on the record formats as well as
links to the lookup API server and some early libraries can be found
here:  https://www.netki.com/#/developers and here:
https://github.com/netkicorp


To break it down briefly, we have an open lookup standard based on
both the namecoin blockchain as well as traditional DNSSEC.  (You can
choose your own adventure of using namecoin based names or traditional
ICANN names).  We DO provide a service where we will register or host
names on your behalf. However if you follow the format and host them
yourself, everything will work just fine, and our open source lookup
server and libraries will provide those results exactly the same as if
the names were hosted with us.  To that end, we have had conversations
with several companies in the space who intend to host their own
names, and we intend to work with them on the effort to ensure our
documentation is sufficient to ensure they can successfully do so.

In terms of comparisons to OpenAlias, I think there are a lot of
similarities, but a few differences.  First the similarities:


1> We both use DNSSEC.

2> We both have the option of storing the address directly in the DNS record.


Differences:

1> We do not use DNSCrypt.  I understand why you chose to, but we were
concerned about broad interoperability and easy broad distribution of
hosting, so decided not to use it.  We have other ways of achieving
privacy, using HD Wallets and Payment Requests.


2> We have the option of storing a URL rather than just a wallet
address in the TXT record.  This allows a second level lookup against
the URL to get back a unique HD Wallet address or Payment Request each
time, further protecting user privacy and security.  Using Wallet
Names with Payment Requests allows for the user experience of typing
in an easy to remember name and getting back the "green lock" and who
the validated recipient is.  This also provides an auto audit of the
end to end DNS SEC process, in the case the path were somehow
compromised, the signature on the payment request can provide an
additional check.


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.

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.


Additionally, we just released another open source API server to help
with the "other half" of the lookup problem.

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin]

Le 14/07/2015 13:19, Milly Bitcoin a écrit :
> 
>> If your email account is hacked and someone else gets a certificate in
>> your name, you'd be unable to *know* about it, because they would use a
>> different CA.
> 
> Maybe I am confused but I thought you are using DNSSEC to sign the zones
> so only the domain owner could issue certificates for a zone (or
> corresponding email address).  If you have "example.com" the domain
> owner of the domain would sign zone "joe.example.com" which can
> correspond to the "j...@example.com" email address.  Under this scenario
> you would only have one CA per domain.
> 

One CA per domain is indeed what I want to achieve. The paragraph you
quoted was about the current situation with email certs, where that is
not the case.
___
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

[Mike Hearn]

Hi Thomas,

Re: NetKi, I think any proposal in this space has to be an open standard,
almost by the definition of what it is. At any rate, it may be worth
talking to them. They have signed up to implement their system at least.

I did understand that your proposal does not rely on email - for instance a
web forum could issue usern...@reddit.com type aliases, even if those are
not also email accounts. I am just continuing the comparison against email
address certs.

It's also the case that a domain can use the DKIM setup without actually
offering email accounts. They can just have a web form or API that triggers
sending of the signed email (or simply, providing the signed headers
themselves). Thus the same system can be used transparently by both email
providers and other sites that don't give their users email addresses, but
would still like to use the same system.

Hardly anyone uses email certificates today, so I don't think it would
> affect a lot of users.


No, but obviously we'd like to change that! The holdup is not the
certificate side of things, really, but rather the lack of a
store-and-forward network for signed payment requests. I keep asking
someone to build one but I fear the problem is almost too simple ..
everyone who looks at this decides to solve 12 other problems
simultaneously, it gets complicated, then they never launch :(

Once there's a simple and robust way to get PaymentRequest's from one end
user to another, even when that first user is offline, then getting an
email cert issued is no big deal.

That does not look so... not until (1) BIP70 wallets integrate with
> https://crt.sh, (2) you convince that service to index email certs (3)
> you convince all CAs to report all email certs they issue to crt.sh.
>

Any solution that separates identity providers from certificate issuers
would have these requirements, though. And as many identity providers today
do not wish to become CAs too, it seems fundamental.

I don't think it's such a problem, mind you. The crt.sh website is actually
a frontend to the CT protocol, which is a somewhat blockchain like audit
log that's eventually intended to contain all issued certificates. Right
now, of course, they focus on SSL certs because those are the most common
and important. If other kinds of certs became more widely used, support in
the infrastructure would follow.



Don't get me wrong - I would like to see a way for a domain to delegate
BIP70 signing power to a third party. For instance, this would mean payment
processors like BitPay could sign on the behalf of the merchant, and the
merchant identity would then show up in wallets. The "chain a cert off a
domain cert" trick would be a good way to do that, though rather than
hacking the X.509 stack to validate invalid stuff, at this point it may as
well be a custom (better) cert format. There's little reason to use X.509
beyond backwards compatibility.

But the most popular identity providers today either don't care about
Bitcoin at all, or worse, are developing competitors to it. So for real
adoption to occur, we must have solutions that do not require identity
provider cooperation. I realise this is a business reason rather than a
technical reason, but it's a very strong one - so bootstrapping off
existing infrastructure with a split CA/ID provider design still makes much
more sense to me.
___
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

[Milly Bitcoin]

If your email account is hacked and someone else gets a certificate in
your name, you'd be unable to *know* about it, because they would use a
different CA.


Maybe I am confused but I thought you are using DNSSEC to sign the zones 
so only the domain owner could issue certificates for a zone (or 
corresponding email address).  If you have "example.com" the domain 
owner of the domain would sign zone "joe.example.com" which can 
correspond to the "j...@example.com" email address.  Under this scenario 
you would only have one CA per domain.


Russ


___
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

[Riccardo Spagni]

Hi Mike,

FYI there is a company called Netki is also working on a kind of DNSSEC
> integration with BIP70, there's a thread here about their efforts:
>
>
>
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J
>
> If you would like to work on this, perhaps it's worth teaming up with them?
> Obviously they plan to have an open spec and open source implementation.
>

Netki's solution is incredibly limited, it's a single return value and no
metadata (where OA encapsulates metadata in KV pairs). This does not lend
itself well to handling BIP70-style communication.

As an aside, they also seem to have a complete disregard for lookup
privacy, which we address in OpenAlias by means of DNSCrypt encrypted
lookups. To that end we have even written the first independent DNSCrypt
implementation (ie. over-and-above dnscrypt-proxy) which provides a full
Python implementation that uses libsodium / nacl if available, but falls
back to a 100% Python slownacl implementation:
https://github.com/openalias/dnscrypt-python

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

[Thomas Voegtlin]

Mike Hearn wrote:

> Hi Thomas,
> 
> FYI there is a company called Netki is also working on a kind of DNSSEC
> integration with BIP70, 
> there's a thread here about their efforts:
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J

Hi Mike,

Thanks! I believe it is better to keep the current discussion on
bitcoin-dev, though.

> If you would like to work on this, perhaps it's worth teaming up with them?
> Obviously they plan to have an open spec and open source implementation.
> 

I would love to work with Netki. However, it's not clear to me what they
are selling. OpenAlias is an open standard, not a company. In contrast,
Netki have very long Terms of Service, that do not help understand what
part of their solution is open-source, and what is the product. They
surely know about OpenAlias, it would be nice to hear what they think
about it.

> Now w.r.t. the other things - I think we have discussed this before, but to
> reiterate:  the biggest flaw with doing things the way you suggest is that
> in practice, no email provider is going to implement your scheme any time
> soon. Most obviously the big web mail providers won't. Therefore hardly
> anyone will use it.
> 

What I propose does not rely on email. Please read again.
I am proposing an alternative way to sign BIP70 requests. This is
independent from the communication channel used to send/receive them.

> Whilst having an extension cannot really hurt, obviously, BIP70 will not be
> amended to reduce the certificate types it allows in favour of a system
> that has a very low chance of mainstream adoption. Restricting options like
> that would just make no sense at all.
> 

Hardly anyone uses email certificates today, so I don't think it would
affect a lot of users. In contrast, it would increase the security of
all users who don't use email certs, because they may receive a payment
request signed by an email cert.

> I think your primary concern is that if your email account is hacked,
> someone could get a cert issued in your name, and you'd be unable to revoke
> it? 

If your email account is hacked and someone else gets a certificate in
your name, you'd be unable to *know* about it, because they would use a
different CA.

> But that's not quite true. Every CA I know of allows you to revoke a
> certificate that was issued for your email address if you have access to
> that email address. Now, if you don't know that this issuance took place,
> you cannot invoke that procedure of course  but that's what certificate
> transparency is already working on solving in a scalable manner:
> 
>   https://crt.sh/
> 
> That site doesn't currently index email address certs, but it certainly
> could with minimal extra effort by the creators as they're almost identical
> to domain name certs.
> 
> So the existing infrastructure seems to have everything in place to solve
> that issue. 

That does not look so... not until (1) BIP70 wallets integrate with
https://crt.sh, (2) you convince that service to index email certs (3)
you convince all CAs to report all email certs they issue to crt.sh.

Good luck with that!


> Now, if you still want a mechanism that eliminates the CA entirely, I think
> there's a better approach which is backwards compatible with existing email
> providers. It works like this: [...]

Again, that olution is for email only. We both agree that this is
solving yesterdays problems, so there's no need to discuss that.
___
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

[Mike Hearn]

Hi Thomas,

FYI there is a company called Netki is also working on a kind of DNSSEC
integration with BIP70, there's a thread here about their efforts:


https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J

If you would like to work on this, perhaps it's worth teaming up with them?
Obviously they plan to have an open spec and open source implementation.

Now w.r.t. the other things - I think we have discussed this before, but to
reiterate:  the biggest flaw with doing things the way you suggest is that
in practice, no email provider is going to implement your scheme any time
soon. Most obviously the big web mail providers won't. Therefore hardly
anyone will use it.

Whilst having an extension cannot really hurt, obviously, BIP70 will not be
amended to reduce the certificate types it allows in favour of a system
that has a very low chance of mainstream adoption. Restricting options like
that would just make no sense at all.

I think your primary concern is that if your email account is hacked,
someone could get a cert issued in your name, and you'd be unable to revoke
it? But that's not quite true. Every CA I know of allows you to revoke a
certificate that was issued for your email address if you have access to
that email address. Now, if you don't know that this issuance took place,
you cannot invoke that procedure of course  but that's what certificate
transparency is already working on solving in a scalable manner:

  https://crt.sh/

That site doesn't currently index email address certs, but it certainly
could with minimal extra effort by the creators as they're almost identical
to domain name certs.

So the existing infrastructure seems to have everything in place to solve
that issue.

Now, if you still want a mechanism that eliminates the CA entirely, I think
there's a better approach which is backwards compatible with existing email
providers. It works like this:

   1. User sends a public key in the subject line to a one-time collector
   address like @publish-email-headers.net(who runs this
   service is arbitrary as they do not need to be trusted). On receiving the
   email, the headers are made available via
   https://publish-email-headers.net/ for download by the
   users wallet.

   2. The act of sending the email triggers DKIM signing of the subject
   line and From header, and thus, the public key and email address are bound
   together via the ESP's own signing key.

   3. The textual email headers can be run through the DKIM validation
   algorithm in combination with the domain key retrieved via DNS.

With this scheme, setup is largely automatic and involves the wallet asking
the operating system to open a mailto: URL. The user just has to press
"send" and the wallet can then sit on a long-lived HTTPS connection waiting
for the headers to turn up. Once the headers are downloaded, they can be
saved to disk and this becomes your "DKIM certificate" which can then be
used with a new pki_type in BIP70.

Note the following useful characteristics of this approach:

   1. It does not require the email provider to know/care about Bitcoin.
   DKIM is already widely deployed by major email providers due to its
   benefits for spam and phishing protection: the majority of all email on the
   internet is DKIM signed. So you automatically have a system that works with
   nearly all consumer email accounts.

   2. The enrolment UI is straightforward, assuming the user has a working
   mailto: handler on their system. Even webmail services like Gmail can
   attach themselves to mailto: handling these days.

   3. There are DKIM validation libraries already in existence, so new code
   required is minimal.

And the downsides:

   1. There is no way to revoke such a "certificate" because you have, of
   course, abandoned the PKI which specifies how to handle all these details.
   You could potentially hijack/reuse OCSP to allow such a custom cert to be
   revoked, but then the question is, who actually runs such a revocation
   server. Doing things like this is why we have CAs in the first place.

   2. The UX leaves a bit of binary nonsense in the users sent folder that
   clutters up their account.

   3. Does it even solve the right problem? A lot of users don't actually
   use emails as identifiers anymore. In the modern world people are using
   their social networking profiles (i.e. Facebook) and phone numbers (e.g.
   for WhatsApp) as the personal identifier of choice. Email address support
   might be solving yesterdays problem.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin]

Dear Bitcoin developers,

I would like to propose an extension of the signature scheme used in
the Payment Protocol (BIP70), in order to authorize payment requests
signed by user@domain aliases, where the alias is verified using
DNSSEC (OpenAlias).

Note that the Payment Protocol already includes the possibility to
sign requests with user@domain aliases, using so-called "SSL email
certificates". Email certificates do not require ownership of a domain
name. They are usually delivered by a trusted CA, to the owner of an
email address.

So, why extend BIP70? Well, I believe that SSL email certificates, as
they exist today, are not well suited for payment requests. The core
issue is that email certificates are not delivered by the entity that
owns the same domain. This has the following implications:

1. No cross-verification. Two different CAs may deliver certificates
   for the same email address. Thus, if a user's mailbox is
   compromised, the hacker can obtain a new certificate for the
   compromised email address, from another CA, and sign payment
   requests with it.  OTOH, if the certificate was delivered by the
   same entity, they could require revokation of the existing
   certificate before issuing a new one. Revocation of a certificate
   would require signing a challenge with the corresponding private
   key.

2. Dilution of responsibilities. Three parties are involved in the
   security of an email certificate: the owner of the email address,
   the CA who signs the certificate, and the owner of the domain
   hosting the email service. If something goes wrong and a user
   claims that a payment request was not signed by them, it is not
   possible to determine who is to blame: the user, the domain owner
   or the CA? Any of these parties could have obtained or issued a new
   certificate.  OTOH, if the alias "user@domain" was issued by
   "domain", we would have clear semantics and clear
   responsibilities. Instead of involving three parties, as in "User X
   hosted at domain Y was verified by trusted authority Z who is not
   shown in the alias", the alias only involves two parties: "user X
   was verified by domain Y". If domain Y misbehaves and issues a
   second certificate for user X, while the first certificate is still
   valid, then the first certificate can serve as a public proof that
   they misbehaved.

3. Lowest common denominator: email is only a communication channel,
   used for authentication by some CAs. Other CAs may decide to use
   other, possibly better, identity verification procedures. However,
   because of the absence of cross verification, the security of the
   whole scheme will always be the security of an email address,
   because it remains the method used by less regarding CAs.

In fact, these issues are so bad that I believe BIP70 should be
amended to reject email certificates.

These issues would be solved, if we could enforce that the user@domain
certificate was delivered by the same entity that controls the domain.
How can we do that? Clearly, we need to change the certificate chain
validation procedure. I see two methods to achieve this:

  1. Keep using TLS and change the certificate chain validation.
  2. Use DNSSEC and Openalias.


Method 1: Modified chain validation.


This introduces a new type of user certificate, where:

 - The commonName is a user@domain alias.
 - The certificate for user@domain must be issued by a domain
   certificate for the same domain (with some rules to allow
   wildcards).
 - Validation of the user@domain certificate does not require the
   issuer certificate to have a CA bit.

This solution would probably be the easiest to deploy, because it uses
TLS certificate chain validation, which is already available in BIP70
compatible wallets. However, it will break compatibility with the
existing certificate validation procedures.


Method 2: DNSSEC and OpenAlias.
---

OpenAlias (http://openalias.org) is a standard for storing Bitcoin
addresses and public keys in DNS TXT records. DNSSEC chain validation
imposes that a record is signed by its parent.

In order to use DNSSEC with BIP70, we may add a new pki_type to BIP70
payment requests (let me call it 'dnssec+btc'), that indicates that
the request has been signed with a Bitcoin public key, and that the
chain validation uses DNSSEC. The chain of signatures may be included
in the payment request.

This solution has my preference. It has been implemented in Electrum
and will be available in version 2.4.



Please let me know what you think. Standardizing that proposal will
probably require a new BIP number, because BIP70 is already final. I
am willing to help doing that. OpenAlias developers have also expressed
their support, and are willing to provide assistance.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo