Delivery-date: Wed, 27 Mar 2024 02:57:31 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) client-ip=2607:f8b0:4864:20::1133;
MIME-Version: 1.0
References: <Zfg/6IZyA/iInyMx@petertodd.org> <012f89763cc336cd91eec13dccefc921@dtrt.org>
In-Reply-To: <012f89763cc336cd91eec13dccefc921@dtrt.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 27 Mar 2024 06:27:47 +0000
Message-ID: <CALZpt+HNiwie1RNJOi9WJs-F2=YSvFdwCDfdNDuTdUuSf_kTBg@mail.gmail.com>
Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
To: "David A. Harding" <dave@dtrt.org>
Cc: Peter Todd <pete@petertodd.org>, bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="0000000000000791e706149e825e"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--0000000000000791e706149e825e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

> Could you tell us more about the disclosure process you followed?  I'm
> surprised to see it disclosed without any apparent attempt at patching.
> I'm especially concerned given your past history of publicly revealing
> vulnerabilities before they could be quietly patched[1] and the conflict
> of interest of you using this disclosure to advocate for a policy change
> you are championing.

In defense of Peter, I don't think there is a low-hanging fruit that could
have
been landed easily in Bitcoin Core. The most obvious ones could have been
a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule
`max_replacement_bandwidth`
or c) a new absolute-fee based penalty on bandwidth replacement cost.

All hard to integrate in a covert fashion without attracting some attention
from the
community, which would certainly ask why we're changing the marginal
bandwidth cost.
Potentially, impacting unfavorably some use-cases.

Certainly, Peter's report could have integrated a disclosure timeline at th=
e
example of CVE-2018-17144 [0], which I can recommend to anyone to follow
doing
security research or servicing as a security point of contact in our field.

I don't see the conflict of interest in the present disclosure ? It is
public information
that Peter is championing RBFR [1].  I'm not aware of any private interest
unfavorably
influencing Peter's behavior in the conduct of this security issue
disclosure.

One of the established principles in infosec, it's up to software vendors
to explain
why their softwares is broken or why they are "lazy" fixing issues.
Assuming sufficient
technical proof has been initially communicated by the reporter.

If you're dissatisfied by Peter's conduct in the handling of this
disclosure, you're welcome
to author vulnerability reports or assume the role of coordinating patching
responses yourself
more often. Assuming you can be reasonably trusted here.

Finally, in matters of ethics, talking as an external observer can be cheap
sometimes and it is
best to "lead-by-example", imho.

Best,
Antoine

[0] https://bitcoincore.org/en/2018/09/20/notice/
[1] https://petertodd.org/2024/one-shot-replace-by-fee-rate


Le mar. 26 mars 2024 =C3=A0 18:38, David A. Harding <dave@dtrt.org> a =C3=
=A9crit :

> On 2024-03-18 03:21, Peter Todd wrote:
> > [...] the existence of this attack is an argument in favor of
> > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the
> > fact
> > that Bitcoin Core's existing rules *also* allow for free-relay in this
> > form
> > makes the difference inconsequential.
> >
> > # Disclosure
> >
> > This issue was disclosed to bitcoin-security first. I received no
> > objections to
> > making it public. All free-relay attacks are mitigated by the
> > requirement to at
> > least have sufficient funds available to allocate to fees, even if the
> > funds
> > might not actually be spent.
>
> Could you tell us more about the disclosure process you followed?  I'm
> surprised to see it disclosed without any apparent attempt at patching.
> I'm especially concerned given your past history of publicly revealing
> vulnerabilities before they could be quietly patched[1] and the conflict
> of interest of you using this disclosure to advocate for a policy change
> you are championing.
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016100.=
html
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/012f89763cc336cd91eec13dccef=
c921%40dtrt.org
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CALZpt%2BHNiwie1RNJOi9WJs-F2%3DYSvFdwCDfdNDuTdUuSf_kTBg%40mail.g=
mail.com.

--0000000000000791e706149e825e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Dave,<div><br></div><div>&gt; Could you tell us more ab=
out the disclosure process you followed?=C2=A0 I&#39;m<span class=3D"gmail-=
Apple-converted-space">=C2=A0</span><br>&gt; surprised to see it disclosed =
without any apparent attempt at patching.=C2=A0<span class=3D"gmail-Apple-c=
onverted-space">=C2=A0</span><br>&gt; I&#39;m especially concerned given yo=
ur past history of publicly revealing<span class=3D"gmail-Apple-converted-s=
pace">=C2=A0</span><br>&gt; vulnerabilities before they could be quietly pa=
tched[1] and the conflict<span class=3D"gmail-Apple-converted-space">=C2=A0=
</span><br>&gt; of interest of you using this disclosure to advocate for a =
policy change<span class=3D"gmail-Apple-converted-space">=C2=A0</span><br>&=
gt; you are championing.<br></div><div><br></div><div>In defense of Peter, =
I don&#39;t think there is a low-hanging fruit that could have</div><div>be=
en landed easily in Bitcoin Core. The most obvious ones could have been</di=
v><div>a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule `max_replacem=
ent_bandwidth`</div><div>or c) a new absolute-fee based penalty=C2=A0on ban=
dwidth replacement cost.</div><div><br></div><div>All hard to integrate in =
a covert fashion without attracting some attention from the</div><div>commu=
nity, which would certainly ask why we&#39;re changing the marginal bandwid=
th=C2=A0cost.</div><div>Potentially, impacting unfavorably some use-cases.<=
/div><div><br></div><div>Certainly, Peter&#39;s report could have integrate=
d a disclosure timeline at the</div><div>example of CVE-2018-17144 [0], whi=
ch I can recommend to anyone to follow doing</div><div>security research or=
 servicing as a security point of contact in our field.</div><div><br></div=
><div>I don&#39;t see the conflict of interest in the present disclosure ? =
It is public information</div><div>that Peter is championing RBFR [1].=C2=
=A0 I&#39;m not aware of any private interest unfavorably</div><div>influen=
cing Peter&#39;s behavior in the conduct of this security issue disclosure.=
</div><div><br></div><div>One of the established principles in infosec, it&=
#39;s up to software vendors to explain</div><div>why their softwares is br=
oken or why they are &quot;lazy&quot; fixing issues. Assuming sufficient</d=
iv><div>technical proof has been initially communicated by the reporter.</d=
iv><div><br></div><div>If you&#39;re dissatisfied by Peter&#39;s conduct in=
 the handling of this disclosure, you&#39;re welcome</div><div>to author vu=
lnerability reports or assume the role of coordinating patching responses y=
ourself</div><div>more often. Assuming you can be reasonably trusted here.<=
/div><div><br></div><div>Finally, in matters of ethics, talking as an exter=
nal observer can=C2=A0be cheap sometimes and it is</div><div>best to &quot;=
lead-by-example&quot;, imho.</div><div><br></div><div>Best,</div><div>Antoi=
ne</div><div><br></div><div>[0]=C2=A0<a href=3D"https://bitcoincore.org/en/=
2018/09/20/notice/">https://bitcoincore.org/en/2018/09/20/notice/</a></div>=
<div>[1]=C2=A0<a href=3D"https://petertodd.org/2024/one-shot-replace-by-fee=
-rate">https://petertodd.org/2024/one-shot-replace-by-fee-rate</a></div><di=
v>=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">Le=C2=A0mar. 26 mars 2024 =C3=A0=C2=A018:38, David A. Hardi=
ng &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; a =C3=A9crit=
=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex">On 2024-03-18 03:21, Peter Todd wrote:<br=
>
&gt; [...] the existence of this attack is an argument in favor of<br>
&gt; replace-by-fee-rate. While RBFR introduces a degree of free-relay, the=
 <br>
&gt; fact<br>
&gt; that Bitcoin Core&#39;s existing rules *also* allow for free-relay in =
this <br>
&gt; form<br>
&gt; makes the difference inconsequential.<br>
&gt; <br>
&gt; # Disclosure<br>
&gt; <br>
&gt; This issue was disclosed to bitcoin-security first. I received no <br>
&gt; objections to<br>
&gt; making it public. All free-relay attacks are mitigated by the <br>
&gt; requirement to at<br>
&gt; least have sufficient funds available to allocate to fees, even if the=
 <br>
&gt; funds<br>
&gt; might not actually be spent.<br>
<br>
Could you tell us more about the disclosure process you followed?=C2=A0 I&#=
39;m <br>
surprised to see it disclosed without any apparent attempt at patching.=C2=
=A0 <br>
I&#39;m especially concerned given your past history of publicly revealing =
<br>
vulnerabilities before they could be quietly patched[1] and the conflict <b=
r>
of interest of you using this disclosure to advocate for a policy change <b=
r>
you are championing.<br>
<br>
-Dave<br>
<br>
[1] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Jun=
e/016100.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2018-June/016100.html</a><br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe<=
/a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=3D"_blank">bit=
coindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/012f89763cc336cd91eec13dccefc921%40dtrt.org" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/0=
12f89763cc336cd91eec13dccefc921%40dtrt.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CALZpt%2BHNiwie1RNJOi9WJs-F2%3DYSvFdwCDfdNDuTdUuSf_kT=
Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.=
google.com/d/msgid/bitcoindev/CALZpt%2BHNiwie1RNJOi9WJs-F2%3DYSvFdwCDfdNDuT=
dUuSf_kTBg%40mail.gmail.com</a>.<br />

--0000000000000791e706149e825e--