Andy Schroder [ARCHIVE] on Nostr: đ Original date posted:2016-08-08 đ Original message:On 08/08/2016 11:00 AM, ...
đ
Original date posted:2016-08-08
đ Original message:On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.
I have mixed feelings about strictly tying the identity-public-keys with
a network identifier. I think the purpose of this is to detect if
someone has physically stolen and compromised my bitcoin node and placed
it on another network under control of an attacker. This seems to be a
bit of a benefit, however, an attacker could always spoof the original
network identifier anyway.
I run my bitcoin node on an internet connection that does not guarantee
a static IP address (although it usually stays the same for several
weeks or months at a time). I'd like to be able to make secure
connections back to my own node, even if I know the IP address may
change from time to time. There are several reasons for wanting to this
with a changing IP. The first is because the bandwidth on my internet
connection with a guaranteed static IP address is considerably more
expensive than my internet connection without a guaranteed static IP
address. The second reason is because the DNS PTR record for my static
IP address is personally identifiable based on other reasons/services.
The internet connection that my bitcoin node is using without a
guaranteed static IP address just has a PTR record that basically
includes my IP address and ISP name. This isn't much use to the general
public (although my ISP obviously knows who I am). The third reason is
that I consider it a good thing from a privacy perspective if my IP
address changes every once and a while.
Maybe a strict check option where the identity-public-keys must
optionally match a specific network identifier would be a compromise?
Maybe this is up to the client implementation to decide, so it should
just be suggested in the BIP rather than required?
> # ___authorized-peers___ contains authorized identity-public-keys
Is there an option for a wildcard here? Couldn't there be a case where
the client wants to authenticate, but the bitcoin node does not care who
it's clients are? This would be similar to many of the http based
bitcoin block explorer API services that are out there. The API
operators have built up some reputation, so people use them, but they
don't necessarily care about who their users are.
> === Local identity key management ===
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
What if I have bitcoind listening on multiple IPv4 interfaces? Can I
have a different identity-key for each IPv4 interface?
Also, would it be possible to only allow this authentication on specific
interfaces? In my example above where I have two internet connections,
if you don't agree to loosening the tie between the network identifier
and the identity-public-keys, maybe I would just connect my bitcoin node
to both internet connections, but only allow a few authorized-peers on
the static IP (which would be low bandwidth), and then not authenticate
on the internet connection with the changing IP at all
If you don't want to increase complexity by adding these options, one
could always accomplish the same thing by runing two instances of
bitcoind and pairing the two over a local network, it would just be a
waste of resources.
> == Disadvantages ==
>
> The protocol may be slow if a peer has a large authorized-peers database
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.
Does openssh have this same problem?
I'm assuming this could be parallelized very easily, so it is not a huge
problem?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/819a2eb5/attachment-0001.sig>;
đ Original message:On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.
I have mixed feelings about strictly tying the identity-public-keys with
a network identifier. I think the purpose of this is to detect if
someone has physically stolen and compromised my bitcoin node and placed
it on another network under control of an attacker. This seems to be a
bit of a benefit, however, an attacker could always spoof the original
network identifier anyway.
I run my bitcoin node on an internet connection that does not guarantee
a static IP address (although it usually stays the same for several
weeks or months at a time). I'd like to be able to make secure
connections back to my own node, even if I know the IP address may
change from time to time. There are several reasons for wanting to this
with a changing IP. The first is because the bandwidth on my internet
connection with a guaranteed static IP address is considerably more
expensive than my internet connection without a guaranteed static IP
address. The second reason is because the DNS PTR record for my static
IP address is personally identifiable based on other reasons/services.
The internet connection that my bitcoin node is using without a
guaranteed static IP address just has a PTR record that basically
includes my IP address and ISP name. This isn't much use to the general
public (although my ISP obviously knows who I am). The third reason is
that I consider it a good thing from a privacy perspective if my IP
address changes every once and a while.
Maybe a strict check option where the identity-public-keys must
optionally match a specific network identifier would be a compromise?
Maybe this is up to the client implementation to decide, so it should
just be suggested in the BIP rather than required?
> # ___authorized-peers___ contains authorized identity-public-keys
Is there an option for a wildcard here? Couldn't there be a case where
the client wants to authenticate, but the bitcoin node does not care who
it's clients are? This would be similar to many of the http based
bitcoin block explorer API services that are out there. The API
operators have built up some reputation, so people use them, but they
don't necessarily care about who their users are.
> === Local identity key management ===
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
What if I have bitcoind listening on multiple IPv4 interfaces? Can I
have a different identity-key for each IPv4 interface?
Also, would it be possible to only allow this authentication on specific
interfaces? In my example above where I have two internet connections,
if you don't agree to loosening the tie between the network identifier
and the identity-public-keys, maybe I would just connect my bitcoin node
to both internet connections, but only allow a few authorized-peers on
the static IP (which would be low bandwidth), and then not authenticate
on the internet connection with the changing IP at all
If you don't want to increase complexity by adding these options, one
could always accomplish the same thing by runing two instances of
bitcoind and pairing the two over a local network, it would just be a
waste of resources.
> == Disadvantages ==
>
> The protocol may be slow if a peer has a large authorized-peers database
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.
Does openssh have this same problem?
I'm assuming this could be parallelized very easily, so it is not a huge
problem?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/819a2eb5/attachment-0001.sig>;