[PROPOSAL] Secure Payment Protocol

[thanke]

But one of the things I've been thinking about for post-1.0 payment protocol specs is incrementally better PKI. We could define our own cert type (protobuf message) that can connect onto the end of an X.509 chain that supports whatever features we need. Then we could indeed put a base ECDSA key into the new cert type. It'd also allow merchants to use their SSL cert to derive certs of lower power that they can hand out to agents of the firm - certs that can only be used for signing Bitcoin payments, and which expire much faster than SSL certs would.

Suppose we define our own (bitcoin-specific) cert type and want to chain it to an existing SSL cert. The SSL cert does not have the CA-flag enabled in the extensions, that would allow it to operate as a CA, i.e. to sign other certs. Do you suggest to simply ignore this flag (at least in v1.0) and have the bitcoin client accept the X.509 chain even though one link does not conform to the X.509 specification? If you did not suggest this, would it very bad if we did ignore this flag (again, in v1.0 only)?

[1714799682]

1714799682

[1714799682]

1714799682

[1714799682]

1714799682

[1714799682]

1714799682

[1714799682]

1714799682

[Mike Hearn]

Yeah, that's exactly what I was proposing.

[Mike Hearn]

I just wanted to point out something that maybe isn't obvious based on the previous discussions. Currently, signing payments offline with SSL keys isn't that useful because most merchants (at least today) don't have their keys in hard-to-compromise places like SSL terminators, they're running off cheap VPS systems and so on. And even if they didn't, control of the web server is often enough to get new SSL keys issued anyway.

But with DNSSEC, that is no longer the case, because the credentials you need to modify DNS are typically kept offline (in admins heads or some other safe place). There's no reason for them to be online. Even if your entire online serving setup is compromised, DNS can stay secure. So if DNSSEC/DANE was implemented as a secondary form of PKI in a future version this use case would make a lot more sense because the payment request signing key could be placed in DNS.

You don't have to lose the self-contained nature of the current payment request protocol. Although it's designed for securing online DNS lookups, DNSSEC is just another PKI - it's conceptually the same as SSL except with the DNS roots taking the place of todays certificate authorities, free signing (as far as I know) and of course it's easier to embed arbitrary data that gets signed as well. But you can still extract all the signatures and keys needed and have them be embedded into the payment request, then checked without any need to reference DNS. It conceptually forms a chain as well.

If somebody asked me to implement a payment protocol that was safe against compromised merchant servers, I'd probably do it by implementing thankes proposal (or the similar one posted in a different thread) and in parallel implementing DNSSEC as an alternative PKI. Then anyone who wants it can generate a new EC key, put the public part into a new DNS record on their domain, and then sign a bunch of payment requests offline. It would be a nice enhancement. It's also complex enough that it'd need to be part of a version 2 effort.

[thanke]

But with DNSSEC, that is no longer the case, because the credentials you need to modify DNS are typically kept offline (in admins heads or some other safe place). There's no reason for them to be online.

I suppose you are saying "to modify SSL" you only need control over the site because of the way EV works. But "to modify DNS" you would need  offline credentials. So far, I can follow. 

Even if your entire online serving setup is compromised, DNS can stay secure. So if DNSSEC/DANE was implemented as a secondary form of PKI in a future version this use case would make a lot more sense because the payment request signing key could be placed in DNS.

Not sure if I get the point here. The payment request signing key can not be replaced because it is in DNSSEC but it's private part would still be compromised, right? I guess the term "payment request signing key" confused me and you mean the private part to be offline, too.

For the design of the payment protocol, I would certainly like to see the PKI as easily exchangeable as possible. And even allow several PKIs in parallel. The bitcoin client should then display to the user for which PKIs authentication was successful, and for which not. 

[Gavin Andresen]

And even allow several PKIs in parallel. The bitcoin client should then display to the user for which PKIs authentication was successful, and for which not.

On one hand:  "Complexity is the enemy of security."  Several PKIs in parallel is more complex.

On the other hand: "Security In Depth."  Several PKIs in parallel could be more secure. But I'd insist that ALL PKI authentications MUST be successful, otherwise you're just giving an attacker the ability to attack the least secure PKI. It would be a mistake to show users a dialog box:

DNSSEC authentication failed, but X.509 certificate authentication succeeded.
Proceed?
(Yes) (No) (Just shoot me now, please)

BUT: I think it is unlikely people will be willing deploy and keep secure multiple PKI systems, and I think the incremental security is small, so I think the right decision here is Keep It Simple, Stupid.

For example, I re-ordered the fields of SignedPaymentRequest so the entire structure doesn't have to be in memory at once to be processed, which is a suggestion from somebody considering implementing the payment protocol on a very memory-constrained hardware device. There are real tradeoffs if we make this more complex.

[Mike Hearn]

Not sure if I get the point here. The payment request signing key can not be replaced because it is in DNSSEC but it's private part would still be compromised, right? I guess the term "payment request signing key" confused me and you mean the private part to be offline, too.

If you are signing requests entirely offline - like in your proposal - then compromising the web server doesn't compromise any private keys.

[Steve]

Maybe it would be good to take a step back when thinking about the problem.  First and foremost what I think you need is a way to deliver a secure message from one node to another, no matter what communication mechanism is employed (and by "secure" I mean signed and encrypted).  Since bitcoin is already using ECC, I see no reason not to use an ECC key pair for this as well.

So, now you have a node, and you generate an ECC key pair for communications.  There are many ways that you could exchange public keys:
- you could email a public key, along with a short hash and verify the short hash with a telephone call
- you could make a public key available on a web server over https with using an SSL certificate and CAs for authentication
- you could sign and send the public key using a PGP identity and PGP key servers
- you could use DNSSEC and whatever that entails (I have no idea, never really studied DNSSEC)

The point is, encrypt and sign the messages from endpoint to endpoint and leave the key exchange and verification protocol outside the scope for now.  With all of the different communications options available (some secure, some not), it seems unfathomable that any payment protocol would not encrypt and sign messages from endpoint to endpoint.

[molecular]

The point of P2C is that no SSL connections are necessary anymore. Example: I go to my local bakery and want to order a birthday cake for tomorrow. The bakery is unexpectedly closed. There is a piece of paper pinned on the door. It says cake A costs 1BTC and cake B costs 2BTC. There is also a table printed on it with the columns "address", "A", "B". I fill out one line with (my home address, 1, 0). I scan a QR-encoded pubkey on the paper with my phone, and, since I have previously shopped with this bakery or otherwise obtained its pubkey, my phone recognizes the pubkey and shows me the name of the bakery, which it has linked to the pubkey. Then I type (home address, 1, 0) into my phone and confirm. Next morning I have one cake A at my door.

All communication between bakery and me can be tampered with by others. But what do they gain? Nothing, except denial-of-service of my order. I may not have a cake, but can show the bakery my receipt and get my money back. They even cannot fool the bakery into making cakes that nobody ordered. So maybe it wasn't so unexpected that the bakery was closed because all their customers  pay with bitcoin

Mr. Hanke, let me thank you for explaining things so even I can understand them .

It's very reassuring to see bitcoin is being recognized and worked on by parts of the german research community, btw. Danke!