Re: [bitcoin-dev] BIP 151

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 10746 bytes --]

I agree.

Encrypting links in a network without identity doesn't really seem to help
enough for the costs to be justified.

I would like to see a PGP-like "web of trust" proposal for both the
security of the bitcoin network itself /and/ (eventually) of things like
transmission of bitcoin addresses.

Something where nodes of any kind (full, spv, mobile wallets) can
/optionally/ accumulate trust over time and are capable of verifying the
identity of other nodes in that web.

*Then* you can slap an encryption layer on top of it.   Once you have
identity & P2P verified pub keys for nodes, encryption becomes easy.


On Thu, Jun 30, 2016 at 5:57 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Jun 29, 2016, at 3:01 AM, Gregory Maxwell <greg@xiph.org> wrote:
> >
> >> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <eric@voskuil.org>
> wrote:
> >> I don't follow this comment. The BIP aims quite clearly at "SPV"
> wallets as its justifying scenario.
> >
> > It cites SPV as an example, doesn't mention bloom filters.. and sure--
> sounds like the bip text should make the
>
> "MOTIVATION:
> The Bitcoin network does not encrypt communication between peers today.
> This opens up security issues (eg: traffic manipulation by others) and
> allows for mass surveillance / analysis of bitcoin users. Mostly this is
> negligible because of the nature of Bitcoins trust model, however for SPV
> nodes this can have significant privacy impacts [1] and could reduce the
> censorship-resistance of a peer."
>
> This is not an example, this is the exception that is described as
> "significant" in comparison to the other issues, which are described as
> "negligible".
>
> The Bloom filters messages are of course the unique aspects of the
> protocol as it pertains to "SPV".
>
> The RISKS section declares that the BIP cannot prevent MITM attacks and
> that "identity authentication" will  be defined in a forthcoming BIP.
>
> The obvious implication (accepted by the author) is that authentication is
> required to prevent a MITM attack, and furthermore establishment of
> identity will be required to ensure that the authenticated party is not a
> bad actor.
>
> >>> Without something like BIP151 network participants cannot have privacy
> for the transactions they originate within the protocol against network
> observers.
> >>
> >> And they won't get it with BIP151 either. Being a peer is easier than
> observing the network.
> >
> > Not passively, undetectable, and against thousands of users at once at
> low cost.
>
> This is a straw man, as the BIP does not state that its objective is to
> moderately raise the cost of passive attack against large numbers of users.
>
> It is also a red herring, as passivity is not itself a benefit. It implies
> that the attack is easier and therefore less costly. But a trivial active
> attack may be a larger security problem than a complex passive attack.
> Attacks against privacy under this BIP (and with authentication) can be
> carried out by passively monitoring traffic and operating one or more
> nodes. Operating a node may be considered "active" because the node
> communicates, but technically it is not. In either case the activeness
> itself hardly raises the difficulty, especially for a global (thousands of
> users) passive attacker.
>
> Depending on the attacker, cost may not be an issue at all, so raising it
> can have zero effect. Certainly we are not talking about prohibitive
> (cryptographically hard) cost. Raising the cost *any* amount is not likely
> a reasonable cost-benefit tradeoff.
>
> Privacy attacks would remain entirely undetectable under this proposal,
> and under any additional proposal that required authentication in the
> absence of identity. Only with all users of the network identified as
> "good" would such proposals be effective. Until that point any bad actors
> can become an integral part of the network. I will investigate the question
> of identity in a follow-up to an independent post.
>
> >> If one can observe the encrypted traffic one can certainly use a timing
> attack to determine what the node has sent.
> >
> > Not against Bitcoin Core, transactions are batched and relayed in
> > sorted order.  (obviously there are limits at what this provides;
> > ironically, the lack of link encryption has been used to argue against
> > privacy preserving relay behavior)
>
> It cannot be both impossible ("not against Bitcoin Core") and limited in
> effectiveness ("obviously there are limits").
>
> We should be clear at this point that the transaction-posting security
> provided against a privacy attack, based on the assumption of "good"
> (identified) peers in the first few hops, derives entirely from the ability
> of the good peers to break the timing attack, which is itself "limited".
>
> This is a compound pair of weak assumptions, that to be made stronger will
> require widespread use of identity (not just authentication).
>
> The proliferation of node identity is my primary concern - this relates to
> privacy and the security of the network. Secondarily I am concerned about
> users operating under a false assumption about the strength of privacy.
> Thirdly I am concerned about the risk of vulnerability introduced by the
> integration into the P2P network layer of an totally new network security
> scheme. Fourthly I'm concerned about the cost of the above based on the
> belief that the benefit may not be material and that it may lead to
> increased centralization.
>
> >>> Even if, through some extraordinary effort, their own first hop is
> encrypted, unencrypted later hops would rapidly
> >>> expose significant information about transaction origins in the
> network.
> >>
> >> As will remain the case until all connections are encrypted and
> authenticated, and all participants are known to be good guys. Starting to
> sound like PKI?
> >
> > Huh? The first and subsequent hops obscures the origin and timing.
>
> Described as "limited" in effectiveness, and clearly useful only if these
> hops are not attacker nodes.
>
> So back to my comment on how we maintain a pool of "good" nodes for people
> to connect to, and raising the question of how effective is this strategy
> (which is itself unspecified and so cannot be assumed to even exist in the
> context of the BIP).
>
> >>> Without something like BIP151 authenticated links are not possible, so
> >>> manually curated links (addnode/connect) cannot be counted on to
> provide protection against partitioning sybils.
> >>
> >> If we trust the manual links we don't need/want the other links. In
> fact retaining the other links enables the attack you described above. Of
> course there is no need to worry about Sybil attacks when all of your peers
> are authenticated. But again, let us not ignore the problems of requiring
> all peers on the network be authenticated.
> >
> > Don't need and want them for what?  For _partitioning_ resistance,
> > you are not partitioned if you have one honest connection to the
> > functional network. Additional peers purely reduce your partition
> vulnerability-- so long as an active network attacker isn't
> > intercepting all your connections out.
>
> Don't want them as peers for the purpose of tx relay. As I said this,
> "enables the attack you described above."
>
> > For privacy, you have improve transaction privacy so long as your
> > transaction isn't initially relayed to a malicious peer-- but
> > malicious peers can lie further out because transit nodes obscure the
> > order of message creation.  Bitcoin Core currently relays transactions
> > first and more frequently to outbound and whitelisted peers.
>
> This whitelisting is simply a stand-in for a more formal identity system.
> One doesn't whitelist anonymous peers, one whitelists peers controlled by
> trusted parties. Preferring trusted peers is another aspect of trying to
> break the timing attack. So I would lump this under the same analysis as
> above (batching).
>
> >> Maybe I was insufficiently explicit. By "relies on identity" I meant
> that the BIP is not effective without it. I did not mean to imply that the
> BIP itself implements an identity scheme. I thought this was clear from the
> context.
> >
> > I understood that, but my point was that Bitcoin cannot be used at
> all_unless users have secure communication channels to share addresses.
>
> This is true but not relevant. The parties with whom we transact are not
> in the same space as the nodes with which we connect. The fact that I am
> face-to-face with a counterparty does not help me find a "good" node, nor
> does my ability to PGP email a payment address or to send a stealth address
> in the clear.
>
> But the fact that you raise this point is itself instructive. The solution
> that was devised to resolve the problem of verifying that a counterparty is
> who one thinks it is ended up being based on the use of certificate
> authorities - despite the fact the the BIP did not require this. Some
> people consider this extremely dangerous for Bitcoin, enough so that Peter
> Todd recently proposed scrapping the BIP.
>
> It's not clear to me how the Bitcoin community intends to establish what
> nodes are good nodes. But one thing is certain, any anonymous node may be
> an undetectable attacker.
>
> >> then there is no reason to expect any effective improvement, since
> nodes will necessarily have to connect with anonymous peers.
> >
> > They're not required to _only_ connect with anonymous peers. And
> partition resistance requires that you have any one good link.
>
> As a minimum requirement, it implies that only need only to connect to one
> or more "good" peers. Anonymous peers are gravy for partition resistance,
> yet they are potential attackers for tx tainting. In other words the
> logical topology is to only connect to good peers. That is a problem.
>
> >> Anyone with a node and the ability to monitor traffic should remain
> very effective.
> >
> > Not via passive observation.
>
> See above commentary on the irrelevance of this distinction.
>
> >> Defining an auth implementation is not a hard problem, nor is it the
> concern I have raised.
> >
> > Glad you agree.
>
> I don't get your point here. It seems like you are just trying to
> antagonize.
>
> > We seem to be looping now. Feel free to not implement this proposal,
>
> At this point I think it's fair for me to say that nobody needs your
> permission.
>
> > no one suggests making it mandatory.
>
> Have you ever debated an optional feature proposal?
>
> e
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 12400 bytes --]