From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WJdNm-0005h8-1a for bitcoin-development@lists.sourceforge.net; Sat, 01 Mar 2014 06:26:46 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co designates 50.117.27.232 as permitted sender) client-ip=50.117.27.232; envelope-from=jeremy@taplink.co; helo=mail.taplink.co; Received: from mail.taplink.co ([50.117.27.232]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1WJdNl-0007DV-9u for bitcoin-development@lists.sourceforge.net; Sat, 01 Mar 2014 06:26:46 +0000 Received: from laptop-air ([192.168.168.135]) by mail.taplink.co ; Fri, 28 Feb 2014 22:26:56 -0800 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "bitcoin-development@lists.sourceforge.net" Date: Fri, 28 Feb 2014 22:26:39 -0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Jeremy Spilman" Organization: TapLink Message-ID: User-Agent: Opera Mail/1.0 (Win32) 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 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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: 1WJdNl-0007DV-9u Subject: [Bitcoin-development] Positive and negative feedback on certificate validation errors 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: Sat, 01 Mar 2014 06:26:46 -0000 We currently have subtle positive feedback of a signed payment request in the form of the green background. Unsigned requests simply show up without the green background, as well as requests which provide a certificate but have a missing or invalid signature. There's a open bug (#3628) and pull request (#3684) to provide negative feedback (yellow background) for a missing or invalid signature, but it seems like there's some debate on whether bitcoind should do that... If an attacker can avoid the negative feedback by just stripping the signature and setting pki_type to none, then arguably there's no security benefit by singling out badly signed payment requests from unsigned payment requests. So perhaps the root problem is that the positive feedback (green background) is not strong enough to make its absence highly conspicuous to the end user. As an aside, how could we go about implementing the equivalent of HTTP Strict Transport Security for payment protocol to prevent this trivial signature stripping attack? Is this a possible extension field merchants are interested in?