Topic: Invoices/Payments/Receipts proposal discussion - page 9. (Read 24728 times)

There's a standard protocol for that but AFAIK most systems don't use it, because it would make the revocation servers a central point of failure for the entire web. Typically certs that get revoked (it's rare) end up in a hard-coded list in the browser source code, so they can be checked locally.

Anyway, all the revocation server does is look up the cert in a list and say "yep! it's revoked!". Your browser is free to ignore this and some of them will let you do so. Revocation is really a non issue, CA's don't have any real power to take back a cert they issued beyond issuing a new statement saying, "whoops our bad". And normally this is not controversial (i.e. the SSL keys were stolen).

Correct. None of them are valid. The interlock protocol does not do what the proposer thinks it does. Read the wikipedia page on it. It's a neat idea but it does not provide authentication. If there's a MITM sitting between you and the merchant, that MITM can rewrite traffic at will.

Bitcoin does not have a public key infrastructure. Using public keys does not mean the same thing as being a PKI. The "infrastructure" part means, how do you know the public key you have corresponds to the entity you think you're communicating with? The last part is tricky because "who you think you're communicating with" is a human, language-based concept, but cryptography works in terms of long random numbers. That's why we need certificates, to join those two worlds.

ZRTP is a method of triggering a Diffie-Hellman key exchange over a VoIP connection. It also isn't any form of authentication mechanism. If you use RedPhone or similar then the assumption is you read out the words you see on your screen, and that the other side checks that the words are the same. It's a neat idea based on the assumption is that a man-in-the-middle like the NSA can't forge your voice. It obviously doesn't work if the two parties don't already know what the other persons voice sounds like, so it's useless for securing a call to (say) a merchant, where you never talked to the salesperson before.

Like Gregory says, authentication and identity are just really hard problems. If you think you found a neat way to avoid all that overhead and hassle by browsing around on Wikipedia, you're probably wrong. Otherwise browser makers would be all over it by now.

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:


The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

Isn't there something like a certificate revocation mechanism, that basically makes your PC to connect to the CA each time you want to use a cert?

I think non-repudiation and other technical side-effects of integrating this protocol with CA signed messages are secondary to the issue at hand.

It is clear that some users of this forum are uncomfortable with the implementation of any solution introducing "centralized" or "trusted" 3rd parties into the Satoshi client. Even though there exists the option to never use this feature, the precedent that's being set is worrisome.

Yes, but if you're going to make the argument that you're being harmed by bitcoin-qt not restricting the freedom of others (an argument I've used here and there at times) I don't think it applies here.

The payment protocol doesn't provide its own secure channel. Thats not what x.509 for is used for in the payment protocol. The use of x.509 in the payment protocol is for non-repudiation (which many secure communications channels don't provide, including SSL).  Without a secure communications channel your privacy/security is hosed, and with one your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

In particular: It's primarily the sender the payment request which cares about the integrity of non-repudiation since if their non-repudiation is compromised customers will be able to convince others that the sender ripped them off.

If someone were making an argument about non-repudiation there might be something to discuss here, but no one appears to be talking about it.

All these "you"s are the person sending the payments request, are they not?

This just isn't how it works. You keep repeating this, but it's nonsensical.

You can transmit a payment request via whatever channel you want. If the x.509 non-repudiation signature in it is not secure you're still secured by whatever channel you're transmitting the data over.  If you have no secure channel at all, your problem is ... kinda out of scope for the payment requests.

What would you have the payment protocol do instead? All you've done so far is list completely inapplicable things that demonstrate that you don't understand what it does at all.

Benign interpretations of NSA's ability to abuse technology companies do not inspire confidence, it assumes we have all of the facts. You can't even assume that Edward Snowden has all the facts, and not all his revelations have been published yet.

It makes more sense to me to be prudent, given the above. We have no control over what content gets delivered in payment request messages; a merchant that didn't disclose personal details one week might suddenly change that the following week, and equally, a merchant that self signs messages might suddenly start using CA signed messages subsequently. The first awareness we end users of these merchants can discover their changing use of the Payments Protocol will be once the potential identity leak has already taken place, when it's too late to choose against it.

I won't be using this protocol until I can somehow be certain that I know what type of information will be in the Payments Protocol message and how the message will be delivered. I want to wear my all-body faraday-cage suit, thankyouverymuch.

Linking a blockchain parser and (even worse) a wallet with any SSL lib is totally unnecessary and hugely irresponsible.

Actually there is an easy solution for it.
There is a minimal version of openssl targetted specifically for low-power embedded devices: cyassl

You are obviously a low-level programmer, so stop wasting time on the forums and perhaps make Bitcoin compatibile with it.

Point taken, however this makes the possible ramifications even worse.
Because the implementation is so efficient and bloat-free, the risk of it becoming "standard" way of doing transactions in the future is even bigger.

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.

But well, if using PKI stays optional, then I think I can live with that. Still, I hope most people will not be using this broken (as of today) functionality.

It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess than the bitcoin at the current stage.

As we have learned recently NSA is probably actively trying to put backdoors wherever they can.
There are reasons to suspect that they had Google to put one into Android's RNG - also an open source code.
I would say that openssl would be one of their targets as well.
But it does not even need to be NSA - it can be just a bug.
All it takes is one bug that would allow to inject an exploit via a stack overflow (e.g. via a "broken" certificate) - and there goes all your money...

None of that list of things actually do anything to address whats the payment protocol is doing.  x.509 is used to provide non-repudiation. The merchant tells you to pay 5 BTC to scriptpubkey X and they'll send you 10 widgets.  If the merchant scams you, you can show other people the signed invoice to convince them that the merchant really did make that agreement.  This means that none of the authentication for ephemeral keying things are actually useful (e.g. every one of your bulleted "alternatives"), nor is "have to trust the merchant not to scam you".

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

Sure, that's a great point!
Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?

You know what, you guys keep doing what you do and in the meantime I will just go to buy some popcorn...
It's gonna be useful when one day I finally get to watch the show, after the great "let's mess it all up even more" approach to the bitcoin development blows right up into your face.

But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".


1. This is not an excuse. Just because some part of Bitcoin is already centralized, should we make it even more centralized thus breaking it even more ? Where's the logic in that ?

2. There are decentralized pools (p2pool and such), just not many people are currently using it.
So mining is or at least *can be* decentralized.

----
Other than above, no more questions for now.

Do take care there, it's not the right comparison.  _Generally_ more CAs == more vulnerable because any CA can author a cert for any domain.

The greater point is that the payment protocol, while it can use x.509 doesn't have security that turns totally brittle even if the CA infrastructure misbehaves.

I'd like to see better support for non-SSL CA stuff, but the options are pretty limited. Doing other things, however, is not mutually exclusive with also supporting x.509.

Updated my answers above. I was close for 1. to 3. 

These questions come up repeatedly, which is why I wrote an FAQ:

    https://bitcointalksearch.org/topic/faq-on-the-payment-protocol-300809

Please do read it. I really think by now that a lot of you will never stop discussing this or going round in circles, but ONE LAST TIME


As I have pointed out multiple times now, what we learned from the Snowden leaks is that the PKI works. The NSA and friends are not engaged in mass forgery of SSL certificates or any other kind of bulk attack on the certificate system, because they are unable to. Instead they are building large databases of whatever private keys they can obtain, via whatever mechanisms can be found.

There was one documented case where a forged certificate appeared to have been used. It was deployed in highly targeted attacks of the kind of that can take out basically any real-world software system. If an entire team of professional hackers goes after you, the chances of them failing are pretty low. The CA targeted could easily have been hacked and never even knew.

But even with that caveat, the certificate transparency upgrade is designed to expose hacked or malicious CA's publicly.

What's more, after Lavabit were forced to give up their SSL private key to the FBI, GoDadddy (the epitome of corporatism) revoked the SSL cert because industry policies required them to. I don't see how the existing set of CA's could have done a better job really, given the enormous scale on which the entire system operates.

But ultimately X.509 does not dictate any particular set of root certs. If you don't like the current set, feel free to go ahead and set up the ShadowOfHarbringer wallet that trusts the ShadowOfHarbringer CA, then start handing out certificates yourself. You can adopt whatever policies you want, including running your CA over Tor and being entirely anonymous.


Given that Bitcoin 0.1 had a payment protocol in it, and he ended up disabling it due to the lack of authentication allowing MITM attacks, I can only assume he'd be fine with bringing it back in a fixed form.

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.


We know already. A few people on bitcointalk will get upset because they have a kneejerk reaction that says "companies == bad". The fact that there's a free market with hundreds of competitors to choose from will be ignored, the fact that they have not proposed anything better will cause them to be ignored. Also calling it "broken by design" is a way to get an insta-ignore because it simply isn't "broken by design", it's exactly the same system used to encrypt the internet connections of over a billion people daily. Rage that it isn't perfect if you like, but it's what we've got.


Go read my FAQ, it's covered very thoroughly there.


You do realize that SSL is exactly the same system supported by the payment protocol, right? You can't use SSL without getting a certificate from this so-called "centralized" system. Realistically all online web shops are expected to use SSL already, as Jeff has pointed out many times. So it doesn't make much difference in the end.


You mean the core client that has a complete cross-platform GUI? It's a reference implementation. Even if not many people choose to use it, it gives developers something to test against and it allows us to verify that what we've designed actually works in the real world. Plus, there are plenty of users who may choose to run a full node wallet, anyone who has a computer switched on 24/7 is a good candidate for using Bitcoin-Qt. With this question, you're really asking "why does anyone bother to maintain the Bitcoin-Qt GUI at all?" which is a topic for another time.

"express strong emotions with an impressionistic style" - hehe. I think Bitcoin has the potential to improve the world. That's why I sometimes become emotional about it.

The shouting was just to stay in the style of the thread My strong emotions against the payment protocol with CA system have somewhat faded as I also see the opportunity of diversification.

From what I understand the payment protocol is by far the largest single addition to the Bitcoin client ever (provocation or truth?). So it is a good idea to think about it twice.

It is very intransparent to me how the decision was made to include it. Is there some decision process? "For a BIP to become Active requires the mutual consent of the community." (https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals)  -  hmmmm.

From an engineering perspective imho the core client should be separated from the GUI and be kept as minimalistic as possible. Hopefully libcoin or libbitcoin will take this role.




I'll go for it  


So everybody can use it and it will penetrate the system ? I tried but I can not find a proper argument.
edit: The Satoshi client is the reference client. It needs to include every important feature so it can be tested.