From: Andy Schroder <info@AndySchroder•com>
To: Gregory Maxwell <greg@xiph•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Authentication BIP
Date: Mon, 8 Aug 2016 13:54:53 -0400 [thread overview]
Message-ID: <57A8C76D.1080405@AndySchroder.com> (raw)
In-Reply-To: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3229 bytes --]
On 08/08/2016 01:42 PM, Gregory Maxwell wrote:
> On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> I have mixed feelings about strictly tying the identity-public-keys with a
> [...]
>> guaranteed static IP address. The second reason is because the DNS PTR
> I don't see any reason that it couldn't also accept a DNS name there.
>
> The purpose of that table is so the client knows which server ID to expect.
Okay, that may be fine. You are saying otherwise you'd have to do a
trial and error and this tying to a network identifier just speeds
things up? If the DNS is spoofed, it's no big deal because the
authentication will fail anyway?
>
>> I consider it a good thing from a privacy perspective if my IP address
>> changes every once and a while.
> And the design seeks to preserve that privacy.
>
>> 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
> The client must know the identity of the server it is expecting. The
> server does not announce itself. If it did then your changing of IPs
> would provide you with no privacy at all.
Good point.
>
> If the design is to provide any protection against MITM you need to
> know who you expected to connect to in any case.
>
>> 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.
> Huh. No. Almost the opposite. The system is designed to inhibit
> fingerprinting. You can't tell what identity key(s) a node has unless
> you already know them. This means that if you don't publish your node
> pubkey, no one can use it to track your node around the network.
Cool.
>
>> 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.
> Then they're just not listed in the file. The client can ask the server to
> authenticate without authenticating itself.
Simple enough.
>
>> Does openssh have this same problem?
> No. OpenSSH doesn't make an effort to protect the privacy of its users.
>
>> I'm assuming this could be parallelized very easily, so it is not a huge
>> problem?
> It's not a issue because we're not aware of any usecase where a node
> would have a large list of authenticated peers.
>
>> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
>
> I'm not aware of any reason for this limitation to exist. A node
> should be able to have as many listening identities as it wants, with
> a similar cost to having a large authorized keys list.
>
So you are saying that you agree with me that the original text needs to
be revised slightly or I am just misinterpreting the original text?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2016-08-08 17:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 15:00 Jonas Schnelli
2016-08-08 17:09 ` Andy Schroder
2016-08-08 17:42 ` Gregory Maxwell
2016-08-08 17:54 ` Andy Schroder [this message]
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=57A8C76D.1080405@AndySchroder.com \
--to=info@andyschroder$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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