public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Schroder <info@AndySchroder.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Authentication BIP
Date: Mon, 8 Aug 2016 13:09:45 -0400	[thread overview]
Message-ID: <57A8BCD9.7050402@AndySchroder.com> (raw)
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>


[-- Attachment #1.1: Type: text/plain, Size: 3877 bytes --]

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?







[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2016-08-08 17:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-08 15:00 [bitcoin-dev] Authentication BIP Jonas Schnelli
2016-08-08 17:09 ` Andy Schroder [this message]
2016-08-08 17:42   ` Gregory Maxwell
2016-08-08 17:54     ` Andy Schroder
2016-08-09 10:02       ` Jonas Schnelli
2016-08-12 12:47         ` Jonas Schnelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57A8BCD9.7050402@AndySchroder.com \
    --to=info@andyschroder.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox