public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev]  Proposal: extend bip70 with OpenAlias
@ 2015-07-14 17:29 Justin Newton
  2015-07-18 13:29 ` Thomas Voegtlin
  0 siblings, 1 reply; 34+ messages in thread
From: Justin Newton @ 2015-07-14 17:29 UTC (permalink / raw)
  To: bitcoin-dev


[-- Attachment #1.1: Type: text/plain, Size: 6197 bytes --]

[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 thomasv@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
<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.  Its in its infancy, and
we are certainly taking feedback on it at this time.  It is called
Addressimo <https://github.com/netkicorp/addressimo> and will serve
unique HD Wallet addresses or Payment Requests for every lookup, thus
allowing a user to have a private, secure way to share a Wallet Name
that can be used to send them any digital currency.

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.


They actually have a really nice way in their standard to encode email
addresses that more or less ensures that there won't be name space
collision in the case that there is already a record "joe.user.com"
and you want to create one for "joe@user.com" that we are looking at
adding to what we are doing in the next update to our record formats.


In any case, I'd much rather we had one effort going forward than
multiples, so let's talk!

[/FROM JUSTIN]




Justin W. Newton
Founder/CEO
NetKi, Inc.

justin@netki.com
+1.818.261.4248

[-- Attachment #1.2: Type: text/html, Size: 9707 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-27 22:46 Riccardo Spagni
  0 siblings, 0 replies; 34+ messages in thread
From: Riccardo Spagni @ 2015-07-27 22:46 UTC (permalink / raw)
  To: 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.smith@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 john@example.com
> _btc.john._oa2.example.com   <--  bitcoin address of john@example.com


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-18 11:40 Riccardo Spagni
  2015-07-18 11:46 ` Mike Hearn
  0 siblings, 1 reply; 34+ messages in thread
From: Riccardo Spagni @ 2015-07-18 11:40 UTC (permalink / raw)
  To: 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


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-17  8:00 Riccardo Spagni
  2015-07-18 11:21 ` Mike Hearn
  0 siblings, 1 reply; 34+ messages in thread
From: Riccardo Spagni @ 2015-07-17  8:00 UTC (permalink / raw)
  To: 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 based validation to
> the DNSSEC chain, not a replacement for it.

Without DANE it's a weakness. It's trusting an additional CA (over and above the
domain owner), when we know that this is - and has been - an issue in the past.
Were it not an issue DANE (or certificate pinning in general) would not have to
exist.

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

(snipped quote for brevity)

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

Coinmarketcap lists 643 currencies and assets, of which only 131 have had more
than $500 in trade volume in the last 24 hours (and only 8 have done over $100
000 in volume). ShapeShift only lists 44 of those. I seriously doubt that a
convenience service such as aliasing will find great use amongst every
fly-by-night scamcoin that crops up, but that is an aside.

> While you may end doing "less lookups" under Open Alias, as it scales, you end
> up causing a significant amount of extra, unnecessary traffic.

"Scale" is a misnomer. Someone trying to collect every single active
cryptocurrency and house them all under a single sub-domain is an outlier, not a
problem to be faced at scale. I do not think we will see a large scale movement
to "collect" all the various cryptocurrency tokens, no matter how worthless they
are, and then subsequently setup aliases for them.

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

I'm not sure how this is any greater leakage than 100 individual requests for
the openly accessible data, especially since it would be encrypted if made via
DNSCrypt?

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

Naughty naughty, you're doing that thing again where you're using a smattering
of expertise to appear knowledgeable about a subject.

So let's hypothetically say that an individual was crazy enough to have all 643
of the Coinmarketcap currencies/assets aliased on a single sub-domain. The
OpenAlias example of a Monero address (with a recipient name) is 157 bytes long,
due to there being two public keys serialised in the address, plus the ~12 bytes
of overhead per RR (the DNS wire format uses label compression, so the FQDN
wouldn't be repeated for each returned record). Let's call it 170 bytes. That
makes the returned data just over 100kb.

Now let's first address a couple of things, assuming that someone would be nuts
enough to do this:

1. This is way larger than the UDP packet maximum, and this would never come
back as a "regular" ol' DNS request (512 bytes max). This may seem bad, until
you consider that DNSSEC responses are almost assured to exceed 512 bytes (eg.
an NXDOMAIN with NSEC3). The size of the response is big, but that's hardly
something to write home about.

2. If the DNS server supports RFC2671 (EDNS) then it would try and send it via
UDP, and as long as the client says it can receive such a huge response over UDP
it'll come over the wire.

3. However, because RFC2671 can result in a DNS amplification attack, it's been
obsoleted by RFC6891 (EDNS0), which is pretty much ubiquitous for all resolvers
that support DNSSEC (because of the very large DNSSEC responses, and the fact
that DNSSEC resolvers want to avoid participation in an amplification attack).
EDNS0 mitigates amplification attacks.

4. In the event that an EDNS0 response fails (eg. the client says it can't
accept anything over, say, 4kb, which is quite common) then there's an automatic
and silent switch to DNS-over-TCP (RFC5966). DNS-over-TCP uses TFO (TCP Fast
Open) to do an extremely fast handshake and passing a cookie to the client in
the SYN-ACK, which can then be used for subsequent requests, but data is still
carried in the SYN. TFO mitigates amplification attacks.

You can't both be overly concerned about amplification attacks *and* use DNSSEC,
which necessitates large records. And, at any rate, the issue with amplification
attacks *isn't* the size of the records (there are tons of records just under
4kb, like an ANY request against isc.org, that are far better suited to
amplification attacks), it is the number of recursive open resolvers. There is
improvement in this space, though, and many open recursive resolvers have been
fixed in recent years.

> It is important to note, that ICANN has "required" for some years that
> registrars and registries support DNSSEC on the domains they register.  I
> personally believe we shouldn't delay use of DNSSEC until their registries had
> come up to current required Internet standards.  (Here are ICANN's registrar
> requirements showing the DNSSEC requirement, btw:
> https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#
> operation)

Doesn't really matter what they require as long as there are zones that remain
unsigned. Plus it's not like new .za / .sg / .to registrations magically get
DNSSEC, they're also out of luck.

> That said, what do others in the industry think?  We are basing our current
> standard on our believed best practices, and defaulted to "first, lose no
> money", given the irreversibility of bitcoin.

Oh, ok. "First, lose no money, but it's ok if your ISP / neighbour / colleague
reports you to the cops because you sent a donation somewhere you shouldn't."

> I think "DNSSEC is hard" is a bit of a boogey man that's not really true.  We
> are working on developing registrar by registrar instructions of how to do
> this, and we have typically found that if you are setting up DNS by yourself,
> adding DNSSEC doesn't take a lot of additional time, maybe an hour or so
> depending on your registrar.

Adding the DS record to a domain is trivial, but to use DNSSEC with Gandi or
GoDaddy (if you don't have their PremiumDNS product) you have to host your own
DNS server. Sorry, but that is a non-trivial task. Even worse: you need to
secure your private KSK and not keep it on the server, and if Bitcoiners are
anything to go by this won't happen.

Oh, and incidentally, ENOM/Namecheap doesn't have DNSSEC support yet.

You're literally layering complexity on top of a convenience service, and to
what end?

> This known concern, however, is why when we launched our product (based on our
> standard record formats) that we wanted to launch it with a variety of options
> for people.

That's completely, 100% centralised. You're creating decentralisation theatre by
providing "options" that no ordinary person will use.

> That's some interesting data, and runs counter to the research of the IETF DNS
> working group.  If you are willing to share your data, I can put you in touch
> with the appropriate folks there to share your research.  I'd also love to see
> it!

I doubt that very much. See:
http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=30

As can be seen, only ~14% of all DNS queries request DNSSEC validation. That's
very far from ubiquitous, and completely matches what Thomas and I found in
Berlin. Unsurprisingly, this stat is particularly bad given that it also shows
that ~15% of all queries are being handled by Google's Public DNS, without which
the stat would be much lower.

> I'd argue that we aren't locking "huge portions" of the Internet.  You are
> correct that about 15% of TLD's are not yet signed, even though they were
> required to be by ICANN.

Fine, so we're just cutting Africa out, then?
http://www.internetsociety.org/deploy360/wp-content/uploads/2015/06/cctlddnssec-
2015-06-19.pdf

Even beyond that, ICANN's page listing DNSSEC-capable registrars (last updated
December 2014) only lists only a handful:
https://www.icann.org/resources/pages/deployment-2012-02-25-en

> As I said above, I believe the requirement to not lose money and the fact that
> other options are available for those running on TLD's that are out of
> compliance, is worth the trade off that some existing names won't work until
> their TLD's come into compliance with current Internet standards.

A soft fail doesn't magically let the money go. It warns users of the risk and
asks them to verify the address by site. This could even be built out so that
higher value transactions (say, anything over $1000) hard fails in the absence
of DNSSEC, and anything particularly high value (say, anything over $50 000)
refuses to use an alias at all and requires an actual cryptocurrency address.

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

Now you're just trolling.

https://github.com/bitpay/copay/pull/2431/files

Which has this lovely line in it:
https://github.com/wdawg33/copay/blob/be6c3e80ab7601d245b186f7802d7050992eb1f0/
config.js#L98

So you provide an open standard that uses DNS...but then you wanted to force
CoPay users to use your centralised API?

> 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 December 2014 your website had no "developer" section (curl -s
https://web.archive.org/web/20141221141023/https://netki.com/ | grep
"Developers")

The first time that section got scraped was the end of April:
https://web.archive.org/web/20150428231016/https://www.netki.com/partials/
developers.html

Even in its current form your website makes no mention of alternatives or
options for those wishing to secure an alias. End users are undoubtedly left
with the distinct impression that they can only get one by paying you.

Riccardo


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-16 16:18 Riccardo Spagni
  0 siblings, 0 replies; 34+ messages in thread
From: Riccardo Spagni @ 2015-07-16 16:18 UTC (permalink / raw)
  To: bitcoin-dev

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

> I appreciate the thought :)  I think where we differ is on where we
> believe the trade offs should be on perceived privacy versus censorship
> resistance and centralization.
>
>
> By having a limited number of proxies people need to go through to easily
> implement, be it the 4 you recommend, or 53, you actually have a very
> limited number of actors for an authority or hacker to go to in order to be
> able to install/force logging, or censorship.  This very centralization
> forces us back to a model where we need to trust a very small number of
> actors in order for the system to operate as designed.  This, to me,
> appears to be the opposite of the goals of the bitcoin ecosystem.  To
> ensure this point is clear, I strongly believe recommending people focus
> all lookups through 4 centralized "proxies" is a bad idea and counter to
> bitcoin's ideals.
>
>
> The fact that hackers or state actors need to corrupt only a small number
> of servers/services in order to gain global visibility into all queries, I
> believe, breaks any perceived privacy gains from using DNSCrypt.  A very
> small number of hacks or subpoenas and everyone's records are fair game in
> one place.
>

You're misstating (or not understanding) the attack surface.

State-level attackers won't compromise 50+ DNSCrypt servers, they can get
the information on lookups a lot more trivially. Censorship resistance and
protection from state-level attackers comes from the decentralised side of
OpenAlias (ie. Namecoin resolution, preferably done using a local copy of
the NMC blockchain). Since Netki supports Namecoin resolution too there is
no need to worry about protecting end users from that.

There is, however, a need to protect users from man-in-the-middle attacks
where the data is not modified en-route, but it is sniffed. Who you pay in
a financial transaction is, and should be, privileged information between
yourself and that person. By encouraging open DNS lookups you're
effectively hanging that information out for all to see.

It is true that there are only 4 DNSCrypt servers we are comfortable
recommending. It is also true that there were, at one stage, only 4
Electrum servers. There were also only 4 Bitcoin nodes. As something grows
and becomes more useful and usable the number of voluntary participants
becomes much greater, and we will provide the necessary tools to enable
these volunteers.

So in a world where tens of thousands of Bitcoiners are using an aliasing
standard (which, in and of itself, is a convenience service anyway), and
hundreds of individuals and companies are hosting DNSCrypt resolvers, is it
even a valid argument to harp on the number of "proxies"? Thus it is not
worth talking about today. It is definitely worth discussing in future if
the number of DNSCrypt resolvers doesn't increase, but that is a different
discussion for a different time.


> For the highly privacy conscious they can, today do their DNS lookups over
> a non logging VPN connection without forcing everyone else through a
> handful of centralized servers.  Or they can use DNSCrypt optionally
> themselves.  All of our tools have always been open source and folks can
> modify them for their own desired uses, or submit pull requests with their
> own ideas.
>

Everyone should be highly privacy conscious when it comes to financial
transactions, and it would be unconscionable of both you and I not to
defend end-user privacy.

We'd love to hear others thoughts on this.  While I believe that for now
> the centralization trade offs required to use DNSCrypt today (via a limited
> number of proxies) outweigh any perceived privacy benefits it provides, we
> are always open to what others in the community believe and have made
> modifications to how things work before as a result of feedback from
> industry participants.
>

It's important to remember that the "paranoid" won't use an aliasing
service, or at best will use a local Namecoin blockchain for that purpose.
This is a convenience service to provide general and broad appeal for the
non-technical, and those are the very people that need to be protected from
nosey neighbours / workmates / ISPs. Privacy is not only (or even at all)
about protecting people buying drugs on a darknet market, it is about
defending personal liberties.

I think DANE is a great idea.  We were just discussing that with Andreas
> S., and are currently looking at whether we want to add this as optional
> versus mandatory, based on how widely available DANE is for folks using
> services like Cloudflare, Akamai, etc for their DNS, which many providers
> in the space today are.
>
> Of course, the security conscious could setup DANE on the URL we use AS
> IS.  There is no need to create a special kv pair for this as is done in
> OpenAlias.  As you know, DNSSEC and HTTPS support this today out of the box.
>

Embedding the TLSA record in a KV pair just means that pinning takes one
less step.


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

Without DANE it's a weakness. It's trusting an additional CA (over and
above the domain owner), when we know that this is - and has been - an
issue in the past. Were it not an issue DANE (or certificate pinning in
general) would not have to exist.


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

(snipped quote for brevity)

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

Coinmarketcap lists 643 currencies and assets, of which only 131 have had
more than $500 in trade volume in the last 24 hours (and only 8 have done
over $100 000 in volume). ShapeShift only lists 44 of those. I seriously
doubt that a convenience service such as aliasing will find great use
amongst every fly-by-night scamcoin that crops up, but that is an aside.

While you may end doing "less lookups" under Open Alias, as it scales, you
> end up causing a significant amount of extra, unnecessary traffic.
>

"Scale" is a misnomer. Someone trying to collect every single active
cryptocurrency and house them all under a single sub-domain is an outlier,
not a problem to be faced at scale. I do not think we will see a large
scale movement to "collect" all the various cryptocurrency tokens, no
matter how worthless they are, and then subsequently setup aliases for them.


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

I'm not sure how this is any greater leakage than 100 individual requests
for the openly accessible data, especially since it would be encrypted if
made via DNSCrypt?


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

Naughty naughty, you're doing that thing again where you're using a
smattering of expertise to appear knowledgeable about a subject.

So let's hypothetically say that an individual was crazy enough to have all
643 of the Coinmarketcap currencies/assets aliased on a single sub-domain.
The OpenAlias example of a Monero address (with a recipient name) is 157
bytes long, due to there being two public keys serialised in the address,
plus the ~12 bytes of overhead per RR (the DNS wire format uses label
compression, so the FQDN wouldn't be repeated for each returned record).
Let's call it 170 bytes. That makes the returned data just over 100kb.

Now let's first address a couple of things, assuming that someone would be
nuts enough to do this:

1. This is way larger than the UDP packet maximum, and this would never
come back as a "regular" ol' DNS request (512 bytes max). This may seem
bad, until you consider that DNSSEC responses are almost assured to exceed
512 bytes (eg. an NXDOMAIN with NSEC3). The size of the response is big,
but that's hardly something to write home about.

2. If the DNS server supports RFC2671 (EDNS) then it would try and send it
via UDP, and as long as the client says it can receive such a huge response
over UDP it'll come over the wire.

3. However, because RFC2671 can result in a DNS amplification attack, it's
been obsoleted by RFC6891 (EDNS0), which is pretty much ubiquitous for all
resolvers that support DNSSEC (because of the very large DNSSEC responses,
and the fact that DNSSEC resolvers want to avoid participation in an
amplification attack). EDNS0 mitigates amplification attacks.

4. In the event that an EDNS0 response fails (eg. the client says it can't
accept anything over, say, 4kb, which is quite common) then there's an
automatic and silent switch to DNS-over-TCP (RFC5966). DNS-over-TCP uses
TFO (TCP Fast Open) to do an extremely fast handshake and passing a cookie
to the client in the SYN-ACK, which can then be used for subsequent
requests, but data is still carried in the SYN. TFO mitigates amplification
attacks.

You can't both be overly concerned about amplification attacks *and* use
DNSSEC, which necessitates large records. And, at any rate, the issue with
amplification attacks *isn't* the size of the records (there are tons of
records just under 4kb, like an ANY request against isc.org, that are far
better suited to amplification attacks), it is the number of recursive open
resolvers. There is improvement in this space, though, and many open
recursive resolvers have been fixed in recent years.

It is important to note, that ICANN has "required" for some years that
> registrars and registries support DNSSEC on the domains they register.  I
> personally believe we shouldn't delay use of DNSSEC until their registries
> had come up to current required Internet standards.  (Here are ICANN's
> registrar requirements showing the DNSSEC requirement, btw:
> https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#operation
> )
>

Doesn't really matter what they require as long as there are zones that
remain unsigned. Plus it's not like new .za / .sg / .to registrations
magically get DNSSEC, they're also out of luck.


> That said, what do others in the industry think?  We are basing our
> current standard on our believed best practices, and defaulted to "first,
> lose no money", given the irreversibility of bitcoin.
>

Oh, ok. "First, lose no money, but it's ok if your ISP / neighbour /
colleague reports you to the cops because you sent a donation somewhere you
shouldn't."


> I think "DNSSEC is hard" is a bit of a boogey man that's not really true.
> We are working on developing registrar by registrar instructions of how to
> do this, and we have typically found that if you are setting up DNS by
> yourself, adding DNSSEC doesn't take a lot of additional time, maybe an
> hour or so depending on your registrar.
>

Adding the DS record to a domain is trivial, but to use DNSSEC with Gandi
or GoDaddy (if you don't have their PremiumDNS product) you have to host
your own DNS server. Sorry, but that is a non-trivial task. Even worse: you
need to secure your private KSK and not keep it on the server, and if
Bitcoiners are anything to go by this won't happen.

Oh, and incidentally, ENOM/Namecheap doesn't have DNSSEC support yet.

You're literally layering complexity on top of a convenience service, and
to what end?

This known concern, however, is why when we launched our product (based on
> our standard record formats) that we wanted to launch it with a variety of
> options for people.
>

That's completely, 100% centralised. You're creating decentralisation
theatre by providing "options" that no ordinary person will use.

That's some interesting data, and runs counter to the research of the IETF
> DNS working group.  If you are willing to share your data, I can put you in
> touch with the appropriate folks there to share your research.  I'd also
> love to see it!
>

I doubt that very much. See:
http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=30

As can be seen, only ~14% of all DNS queries request DNSSEC validation.
That's very far from ubiquitous, and completely matches what Thomas and I
found in Berlin. Unsurprisingly, this stat is particularly bad given that
it also shows that ~15% of all queries are being handled by Google's Public
DNS, without which the stat would be much lower.

I'd argue that we aren't locking "huge portions" of the Internet.  You are
> correct that about 15% of TLD's are not yet signed, even though they were
> required to be by ICANN.
>

Fine, so we're just cutting Africa out, then?
http://www.internetsociety.org/deploy360/wp-content/uploads/2015/06/cctlddnssec-2015-06-19.pdf

Even beyond that, ICANN's page listing DNSSEC-capable registrars (last
updated December 2014) only lists only a handful:
https://www.icann.org/resources/pages/deployment-2012-02-25-en

As I said above, I believe the requirement to not lose money and the fact
> that other options are available for those running on TLD's that are out of
> compliance, is worth the trade off that some existing names won't work
> until their TLD's come into compliance with current Internet standards.
>

A soft fail doesn't magically let the money go. It warns users of the risk
and asks them to verify the address by site. This could even be built out
so that higher value transactions (say, anything over $1000) hard fails in
the absence of DNSSEC, and anything particularly high value (say, anything
over $50 000) refuses to use an alias at all and requires an actual
cryptocurrency address.

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

Now you're just trolling.

https://github.com/bitpay/copay/pull/2431/files

Which has this lovely line in it:
https://github.com/wdawg33/copay/blob/be6c3e80ab7601d245b186f7802d7050992eb1f0/config.js#L98

So you provide an open standard that uses DNS...but then you wanted to
force CoPay users to use your centralised API?

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 December 2014 your website had no "developer" section (curl -s
https://web.archive.org/web/20141221141023/https://netki.com/ | grep
"Developers")

The first time that section got scraped was the end of April:
https://web.archive.org/web/20150428231016/https://www.netki.com/partials/developers.html

Even in its current form your website makes no mention of alternatives or
options for those wishing to secure an alias. End users are undoubtedly
left with the distinct impression that they can only get one by paying you.

Riccardo

PS. your mail won't go to the list if you CC the list address, you may want
to resend it

>

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-14 19:07 Riccardo Spagni
  2015-07-17  0:55 ` Justin Newton
  0 siblings, 1 reply; 34+ messages in thread
From: Riccardo Spagni @ 2015-07-14 19:07 UTC (permalink / raw)
  To: bitcoin-dev

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

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

2. Even if the zone *is* signed, DNSSEC deployment is hard. Unmanaged
DNSSEC deployment is out of scope for probably 99.9% of users, even the
usually-technically-ok Bitcoin crowd. Managed DNSSEC is available, but is
quite pricey. UltraDNS, Dyn, and GoDaddy (ikr?) are the three big
providers, and of those three only GoDaddy has a consumer-affordable
product.

3. ThomasV and I have done a stack of testing behind residential and
commercial routers where DNSSEC simply fails (eg. the router runs a really
outdated DNS server that doesn't provide RRSIGs in its response, or the ISP
doesn't care about DNSSEC). Unsurprisingly, this can be fixed by...you
guessed it...doing the lookup via DNSCrypt.

Until we are closer to the bulk of all TLDs being signed, and DNSSEC
becomes at least a little more ubiquitous, we can't lock out huge portions
of the Internet, because then we're not really providing a useful and
usable solution. All we can is make it more difficult to pay an unverified
domain.

Of course, if your aim is to force people to use you as a domain registrar,
then it makes total sense why you'd lock people out;)

Additionally, we just released another open source API server to help
> with the "other half" of the lookup problem.  Its in its infancy, and
> we are certainly taking feedback on it at this time.  It is called
> Addressimo <https://github.com/netkicorp/addressimo> and will serve
> unique HD Wallet addresses or Payment Requests for every lookup, thus
> allowing a user to have a private, secure way to share a Wallet Name
> that can be used to send them any digital currency.
>

Oh snap...https://github.com/openalias/openalias-api


> 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.
>
>
> They actually have a really nice way in their standard to encode email
> addresses that more or less ensures that there won't be name space
> collision in the case that there is already a record "joe.user.com"
> and you want to create one for "joe@user.com" that we are looking at
> adding to what we are doing in the next update to our record formats.
>

OpenAlias (and your system) doesn't really have to worry about that, as TXT
records can live side-by-side with A / CNAME / MX etc. records. More
importantly, OpenAlias especially doesn't have to worry about it, because
OpenAlias TXT records have a prefix: "oa1:" for OpenAlias v1 records. The
risk of there being a legitimate TXT record that starts with oa1: and
*isn't* an OpenAlias record is, well, pretty negligible.

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.

Riccardo

Footnotes:

[1] -
https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv
[2] - http://stats.research.icann.org/dns/tld_report/

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-14  8:29 Riccardo Spagni
  0 siblings, 0 replies; 34+ messages in thread
From: Riccardo Spagni @ 2015-07-14  8:29 UTC (permalink / raw)
  To: bitcoin-dev

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

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

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
@ 2015-07-13 22:31 Mike Hearn
  2015-07-14  6:42 ` Thomas Voegtlin
  0 siblings, 1 reply; 34+ messages in thread
From: Mike Hearn @ 2015-07-13 22:31 UTC (permalink / raw)
  To: bitcoin-dev, thomasv

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

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 <random-number>@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/<random-number> 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.

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
[parent not found: <55A3B52C.9020003@electrum.org>]
end of thread, other threads:[~2015-07-31 20:34 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-14 17:29 [bitcoin-dev] Proposal: extend bip70 with OpenAlias Justin Newton
2015-07-18 13:29 ` Thomas Voegtlin
2015-07-18 23:01   ` Justin Newton
2015-07-20  8:56     ` Thomas Voegtlin
  -- strict thread matches above, loose matches on Subject: below --
2015-07-27 22:46 Riccardo Spagni
2015-07-18 11:40 Riccardo Spagni
2015-07-18 11:46 ` Mike Hearn
2015-07-17  8:00 Riccardo Spagni
2015-07-18 11:21 ` Mike Hearn
2015-07-16 16:18 Riccardo Spagni
2015-07-14 19:07 Riccardo Spagni
2015-07-17  0:55 ` Justin Newton
2015-07-17  0:58   ` Justin Newton
2015-07-17  1:01   ` Justin Newton
2015-07-17  1:02     ` Justin Newton
2015-07-23  9:48     ` Thomas Voegtlin
2015-07-23 13:07       ` Thomas Voegtlin
2015-07-27 21:51         ` Justin Newton
2015-07-31 20:34           ` Thomas Voegtlin
2015-07-14  8:29 Riccardo Spagni
2015-07-13 22:31 Mike Hearn
2015-07-14  6:42 ` Thomas Voegtlin
2015-07-14 11:19   ` Milly Bitcoin
2015-07-14 13:13     ` Thomas Voegtlin
2015-07-14 11:45   ` Mike Hearn
2015-07-19 11:18     ` Thomas Voegtlin
2015-07-20 13:46       ` Mike Hearn
2015-07-20 14:32         ` Thomas Voegtlin
2015-07-20 14:42           ` Mike Hearn
2015-07-20 14:52             ` Thomas Voegtlin
2015-07-20 15:14               ` Mike Hearn
2015-07-20 15:34                 ` Thomas Voegtlin
2015-07-20 16:09                   ` Mike Hearn
     [not found] <55A3B52C.9020003@electrum.org>
2015-07-13 13:06 ` Thomas Voegtlin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox