Re: [bitcoin-dev] Authentication BIP

[Jonas Schnelli via bitcoin-dev]

Hi Andy

>>
>>> 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?

Yes. I think this limitation could be removed.
A responding node can have – in theory – multiple identity-keys per
network interface (network interfaces is also confusing, because you
could run multiple bitcoind instances on the same interface with
different ports).

The BIP should just make clear, that it is probably wise, to use
different identity-keys for each network interface (ipv4, v6, tor).

I'll try to overhaul that part.





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Authentication BIP

[Andy Schroder via bitcoin-dev]

On 08/08/2016 01:42 PM, Gregory Maxwell wrote:

On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
 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?





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Authentication BIP

[Gregory Maxwell via bitcoin-dev]

On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
 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.

> 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.

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.

> 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.

> 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev