From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WgJ1o-00066u-NC for bitcoin-development@lists.sourceforge.net; Fri, 02 May 2014 19:21:48 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.41 as permitted sender) client-ip=209.85.219.41; envelope-from=voisine@gmail.com; helo=mail-oa0-f41.google.com; Received: from mail-oa0-f41.google.com ([209.85.219.41]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WgJ1n-0006ik-FO for bitcoin-development@lists.sourceforge.net; Fri, 02 May 2014 19:21:48 +0000 Received: by mail-oa0-f41.google.com with SMTP id m1so3151531oag.14 for ; Fri, 02 May 2014 12:21:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.243.138 with SMTP id wy10mr2198225obc.83.1399058501732; Fri, 02 May 2014 12:21:41 -0700 (PDT) Received: by 10.60.45.231 with HTTP; Fri, 2 May 2014 12:21:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 May 2014 12:21:41 -0700 Message-ID: From: Aaron Voisine To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (voisine[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WgJ1n-0006ik-FO Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70 implementation guidance X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 19:21:48 -0000 At the moment BIP70 specifically requires that a request be rejected if validation fails, so that should be fixed that sooner rather than later: "The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs." Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 8:39 AM, Mike Hearn wrote: > A bunch of different people either have implemented or are implementing > BIP70 at the moment. Here's a bunch of things I've been telling people in > response to questions. At some point I'll submit a pull req with this stuff > in but for now it's just an email. > > Error handling during signature checking > > I've had queries around the right behaviour here. BIP 70 is underspecified > and we should fix it IMO. If PKI checking fails you should just treat the > request as if it's unsigned. The reason is that there is no incentive for an > attacker to break the signature instead of just removing it entirely, so an > attacker would never trigger any error flows you put in. However, someone > who is signing their request with an unknown CA or using an upgraded version > of the protocol that isn't entirely backwards compatible could trigger > signature checking failure. > > Therefore, in order to make introducing new (possibly community run) CA's or > new variations on signing possible, please treat any errors as if there was > no signature at all. This is not what browsers do, but browsers have an > advantage - they were already given an identity and told to expect a secure > protocol when the user typed in the web address with an https:// prefix (or > clicked a link). Unfortunately a Bitcoin wallet has no context like this. > > One person asked me whether this makes the whole scheme pointless because a > MITM can just delete the signature. The answer is no - downgrade attacks are > always possible on systems that start out insecure. The solution is to train > users to expect the upgrade and refuse to go ahead if it's not there. > Training users to expect signed payment requests will be a big task similar > to the way the browser industry trained users to look for the padlock when > typing in credit card details, but it must be done. > > Because wallets lack context there's no equivalent to HSTS for us either. So > in your GUI's try to train the user - when showing a signed payment request, > tell them to expect the recipient name to appear in future and that they > should not proceed if it doesn't. This gives us a kind of mental HSTS. > > Extended validation certs > > When a business is accepting payment, showing the name of the business is > usually better than showing just the domain name, for a few reasons: > > Unless your domain name is your business name like blockchain.info, it looks > better and gives more info. > > Domain names are more phishable than EV names, e.g. is the right name > bitpay.com or bit-pay.com or bitpay.co.uk? > > More important: Someone who hacks your web server or DNS provider can > silently get themselves a domain name SSL cert issued, probably without you > noticing. Certificate transparency will eventually fix that but it's years > away from full deployment. It's much harder for a hacker to get a bogus EV > cert issued to them because there's a lot more checking involved. > > EV certs still have the domain name in the CN field, but they also have the > business name in the OU field. > > In theory we are supposed to have extra code to check that a certificate > really was subject to extended validation before showing the contents of > this field. In practice either bitcoinj nor Bitcoin Core actually do, they > just always trust it. It'd be nice to fix that in future. > > You should show the organisation data instead of the domain name if you find > it, for EV certs. > > pki=none > > Signing is optional in BIP 70 for good reasons. One implementor told me they > were considering rejecting unsigned payment requests. Do not do this! A MITM > can easily rewrite the bitcoin URI to look as if BIP70 isn't in use at all. > > Even though today most (all?) payment requests you'll encounter are signed, > it's important that signing is optional because in future we need individual > people to start generating payment requests too, and many of them won't have > any kind of memorisable digital identity. Plus other people just won't want > to do it. BIP70 is about lots of features, signing is only one. > > S/MIME certs > > Email address certs look a bit different to SSL certs. You can get one for > free from here > > https://comodo.com/home/email-security/free-email-certificate.php > > In these certs the display name can be found in the Subject Alternative Name > field with a type code of 1. Example code: > > > https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d > > You won't encounter many of these today except on Gavin's test site, but in > future people may wish to start creating and signing their own payment > requests for individual purposes using these certs (especially as they are > free). So please try to handle them correctly. > > Broadcast vs upload > > Please upload transactions and commit them to your wallet when the server > responds with 200 OK, but expect the merchant to broadcast them. Don't give > the user an option to pick - it's pointless as there's no obvious right > answer. > > Testing > > You can find a test site here: > > http://bitcoincore.org/~gavin/createpaymentrequest.php > > It's testnet only. For testing regular payment requests on the main network, > I use BitPay as they were the first seller-side implementation: > > http://bitgivefoundation.org/donate-now/ > > Memo contents > > Please put something useful here, ideally what is actually being sold but > failing that, the name of the merchant if you're a payment processor. Don't > be like BitPay and put large random numbers in the memo field but nothing > about what's actually purchased. > > This is not particularly important today except for cosmetic reasons, > because wallets don't store the payment requests they saw to disk. But in > future they will and then a properly signed memo field + the transactions > used for payment give us a digital receipt. Receipts are useful for things > like filing expense reports, proving a purchase when returning an item to a > merchant, etc. > > Expiry times > > Don't be too aggressive with these. Although today it doesn't matter much, > some users may be trying to pay from multi-party accounts that require > multiple humans to coordinate to make a payment. > > > > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >