Published on: 2016-08-12T12:47:31+00:00
The discussion revolves around the privacy protection of OpenSSH users and the comparison with Bitcoin Core. It is noted that OpenSSH does not prioritize user privacy like Bitcoin Core does. In the discussion, it is suggested that OpenSSH should allow multiple identity-keys per network interface to enhance privacy. The proposal includes using different identity-keys for each network interface. The relevant changes to the proposal can be viewed on GitHub.In the bitcoin-dev mailing list conversation, members discuss whether identity-public-keys should be tied to static IP addresses or if DNS names should be allowed. The purpose of this table is to inform clients which server ID to expect. The design aims to inhibit fingerprinting and prevent tracking unless pubkeys are published. To protect against MITM attacks, the client must know the expected server identity. The idea of allowing wildcard options is raised, but it is clarified that such nodes would not be listed and clients could request authentication without authenticating themselves. The limitation of one identity-key per listening network interface for each node is questioned, suggesting that nodes should be able to have multiple identities at a similar cost to having a large authorized keys list.Andy Schroder expresses mixed feelings about tying identity-public-keys with static IP addresses in a bitcoin-dev post and suggests supporting DNS names in addition to IP addresses. The purpose of the table remains to identify the expected server ID, while also preserving privacy in case of IP address changes. MITM attacks are prevented by ensuring the client knows the server's identity. OpenSSH is mentioned as not prioritizing user privacy like Bitcoin does. The limitation of only one identity-key per listening network interface is questioned, advocating for the ability to have multiple identities with a similar cost to managing a large authorized keys list.Jonas Schnelli raises concerns about the format of known-peers and authorized-peers files, questioning the strict tie between identity-public-keys and network identifiers due to potential spoofing. For individuals running a Bitcoin node with a dynamic IP address, secure connections back to their own node may be desired. A suggestion is made for a compromise between strict checks and wildcard options. It is unclear if different identity-keys can be used for each IPv4 interface, and one solution proposed is running two instances of bitcoind and pairing them over a local network. The disadvantage mentioned is the potential slowness when dealing with a large authorized-peers database.Jonas Schnelli proposes an authentication scheme to detect and reject MITM attacks in conjunction with BIP151. This requires building trusted connections, and the authentication process uses ECDSA without transmitting secrets. The identity-public-keys used for authentication must be shared over a different channel. Each peer supporting p2p authentication must maintain an editable "database" for authentication state until the encryption/connection terminates. Only one authentication process is allowed per connection. Peers should display/log the identity-public-key as an identity-address to users, encoded as a base58-check ripemd160(sha256) hash.
Updated on: 2023-08-01T18:50:48.866575+00:00