From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6840DC0032 for ; Sun, 13 Aug 2023 07:08:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 30806402F5 for ; Sun, 13 Aug 2023 07:08:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 30806402F5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIQSJDW809M0 for ; Sun, 13 Aug 2023 07:08:28 +0000 (UTC) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5073F40102 for ; Sun, 13 Aug 2023 07:08:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5073F40102 Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id D3E392800085; Sun, 13 Aug 2023 00:08:24 -0700 (PDT) Received: from [127.0.0.1] (62.red-79-152-142.dynamicip.rima-tde.net [79.152.142.62]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Sun, 13 Aug 2023 00:08:24 -0700 (PDT) Date: Sat, 12 Aug 2023 20:58:29 -1000 From: "David A. Harding" To: AdamISZ , Bitcoin Protocol Discussion User-Agent: K-9 Mail for Android In-Reply-To: References: <7B11AE34-27A7-46ED-95BF-66CA13BA26F3@ngould.dev> Message-ID: <9E89DE36-4CB4-4F16-A702-FE33EDF544C3@dtrt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 3b1c.64d88168.4a73e.0 Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2023 07:08:29 -0000 On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev wrote: >Hi Dan, >A couple more more thoughts: > >> Out of band, the receiver of the payment, shares a bitcoin URI with the= sender including a pj=3D query parameter describing the relay= subdirectory endpoint and psk=3D parameter with base64 encode= d 256-bit secret key=2E > >You're sending the symmetric secret key out of band; but isn't this obscu= ring the question of securely sharing the secret key? Did you consider DH-i= ng this as other protocols do? At the very least I would claim that it's li= kely that implementers might be sloppy here; at the most I would claim this= is just insecure full stop=2E Hi Dan, After reading Adam's comments above and re-reading your draft BIP where it= says the secret key is also used as the session identifier and that output= s can be modified, I'm wondering about the security of posting payment URIs= anywhere someone can see them=2E For example, if Alice posts her BIP21 URI for Bob to pay where Eve can see= it, such as in a shared chatroom or via email or any cleartext protocol th= at gets relayed, can Eve establish her own session to the relay and frontru= n Alice on receiving Bob's PSBT, modify the returned PSBT to include her (E= ve's) output, and submit it for Bob to sign and broadcast? The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, = posting them where evesdroppers can see them poses a privacy risk but not a= risk of loss of funds, so many users don't treat them as especially hazard= ous material=2E I don't think it would be practical to change that expecta= tion, and I think a protocol where evesdropping didn't create a risk of fun= ds loss would be much better than one where that risk was created=2E (Apologies to Adam is this is exactly what he was saying with more subtly= =2E) -Dave