Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.176 as permitted sender)
	client-ip=209.85.213.176; envelope-from=laanwj@gmail.com;
	helo=mail-ig0-f176.google.com; 
MIME-Version: 1.0
In-Reply-To: <06D9FBBD-30DB-4591-A932-B5A19F1D6543@coinqy.com>
References: <mailman.342174.1410547421.2163.bitcoin-development@lists.sourceforge.net>
	<06D9FBBD-30DB-4591-A932-B5A19F1D6543@coinqy.com>
Date: Sat, 13 Sep 2014 10:53:34 +0200
Message-ID: <CA+s+GJBWTji2JfTF+8+zb+9LWV2mK7inqVakdMhoXQYi4_a-Jw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Mark van Cuijk <mark@coinqy.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
Precedence: list

On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk <mark@coinqy.com> wrote:
> If you do so, please make sure the length of the hash is included in the =
PaymentDetails/PaymentRequest. If someone parses the URI and doesn=E2=80=99=
t have an authenticated way of knowing the expected length of the hash, a M=
ITM attacker can just truncate the hash to lower security.

But if they can truncate they can just as well pass a completely
different hash that matches their payment request. If an attacker can
change the bitcoin: URI, this scheme is broken.

The point of the proposal is to make sure that the payment request
matches the URI. So *if* you communicate the URI by secure means, this
authenticates the associated payment request as well, even if fetched
by insecure means (such as http:...) itself.

Wladimir