Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V4UR2-0005LG-B1 for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 11:19:16 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.169 as permitted sender) client-ip=74.125.82.169; envelope-from=gavinandresen@gmail.com; helo=mail-we0-f169.google.com; Received: from mail-we0-f169.google.com ([74.125.82.169]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V4UQx-000078-Td for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 11:19:16 +0000 Received: by mail-we0-f169.google.com with SMTP id n5so485536wev.14 for ; Wed, 31 Jul 2013 04:19:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr3889018wib.52.1375269545702; Wed, 31 Jul 2013 04:19:05 -0700 (PDT) Received: by 10.194.82.198 with HTTP; Wed, 31 Jul 2013 04:19:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 21:19:05 +1000 Message-ID: From: Gavin Andresen To: Mike Hearn Content-Type: multipart/alternative; boundary=f46d044517f7bdfe7a04e2cce4b1 X-Spam-Score: -0.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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1V4UQx-000078-Td Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Wed, 31 Jul 2013 11:19:16 -0000 --f46d044517f7bdfe7a04e2cce4b1 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Mike! "PaymentRequest messages larger than 50,000 bytes should be rejected by > the merchant's server, to mitigate denial-of-service attacks." > > Do you mean "users wallet" here? > Yes, fixed. > You could note in the motivation section two more motivations: > 1) That the protocol can be a foundation on which other features are built > I don't like putting "this is what we think will happen in the future" types of statements in specifications, so I'm inclined to leave that out. > 2) That it is required to assist hardware wallets when there is a virus on > the system > Added: "Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet." Perhaps note in the BIP that the merchant should not assume the > merchant_data field is trustworthy - malicious buyers could rewrite it as > they see fit. Point out that a good way to use this is to serialize server > state, signed by a merchant-only key, in the same way one might use an HTTP > cookie. > Added: "Note that malicious clients may modify the merchant_data, so should be authenticated in some way (for example, signed with a merchant-only key)." > "PaymentDetails.payment_url must be secure against man-in-the-middle > attacks that might alter Payment.refund_to (if using HTTP, it must be > TLS-protected). > > This says "must", but what should a client do here if the payment URL is > not HTTPS? I suggest weakening this to "should", as sometimes TLS is > redundant (e.g. if you're sending to a Tor hidden service). > done. > The PaymentACK message contains a copy of Payment, but the BIP doesn't say > what to do with it. I assume this means a client is free to ignore it and > rely on TCP state to figure out the payment/ack connection instead? It may > be worth noting that explicitly. > Added: "payment | Copy of the Payment message that triggered this PaymentACK. Clients may ignore this if they implement another way of associating Payments with PaymentACKs." > > In the certificates section, you could observe that "validation" means > "verification that it correctly chains to a trusted root authority, where > trusted roots may be obtained from the operating system. If there is no > operating system, the Mozilla root store is recommended". > Modified that section to say: "...followed by additional certificates, with each subsequent certificate being the one used to certify the previous one, up to a trusted root authority. The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs. Trusted root certificates may be obtained from the operating system; if validation is done on a device without an operating system, the Mozilla root store is recommended." -- -- Gavin Andresen --f46d044517f7bdfe7a04e2cce4b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Mike!

=A0 =A0"Pa= ymentRequest messages larger than 50,000 bytes should be rejected by the me= rchant's server, to mitigate denial-of-service attacks."

Do you mean "users wallet" here?
=

Yes, fixed.

=A0
= You could note in the motivation section two more motivations:
1) That the protocol can be a founda= tion on which other features are built
=
I don't like putting "this is what we think will ha= ppen in the future" types of statements in specifications, so I'm = inclined to leave that out.
=A0
2) That it is required to assist hardware wallets= when there is a virus on the system

Added:

&quo= t;Resistance from man-in-the-middle atta= cks that replace a merchant's bitcoin address with an attacker's ad= dress before a transaction is authorized with a hardware wallet."

Perhaps note in the BIP that the mer= chant should not assume the merchant_data field is trustworthy - malicious = buyers could rewrite it as they see fit. Point out that a good way to use t= his is to serialize server state, signed by a merchant-only key, in the sam= e way one might use an HTTP cookie.
=A0
Added:

"= ;Note that malicious clients may modify = the merchant_data, so should be authenticated in some way (for example, sig= ned with a merchant-only key)."
=A0
=A0 =A0"PaymentDetails.payment_u= rl must be secure against man-in-the-middle attacks that might alter Paymen= t.refund_to (if using HTTP, it must be TLS-protected).

This says "must", but what should a cl= ient do here if the payment URL is not HTTPS? I suggest weakening this to &= quot;should", as sometimes TLS is redundant (e.g. if you're sendin= g to a Tor hidden service).

done.
=A0
The Payme= ntACK message contains a copy of Payment, but the BIP doesn't say what = to do with it. I assume this means a client is free to ignore it and rely o= n TCP state to figure out the payment/ack connection instead? It may be wor= th noting that explicitly.

Added:

&quo= t;payment | Copy of the Payment message that triggered this PaymentACK. Cli= ents may ignore this if they implement another way of associating Payments = with PaymentACKs."
=A0

In the certificates section= , you could observe that "validation" means "verification th= at it correctly chains to a trusted root authority, where trusted roots may= be obtained from the operating system. If there is no operating system, th= e Mozilla root store is recommended".

Modified that section to say:

"...followed by additional certificates, with each su= bsequent certificate being the one used to certify the previous one, up to = a trusted root authority. The recipient must verify the certificate chain a= ccording to [RFC5280] and reject the PaymentRequest if any validation failu= re occurs.

Trusted root certifi= cates may be obtained from the operating system; if validation is done on a= device without an operating system, the=A0Mozilla root= store=A0is recommended."


--
--
Gavin Andresen
--f46d044517f7bdfe7a04e2cce4b1--