Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-08 📝 Original message:On 08/08/2016 01:42 PM, ...
📅 Original date posted:2016-08-08
📝 Original message: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 at 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?
-------------- 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/35f0fa9d/attachment.sig>;
📝 Original message: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 at 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?
-------------- 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/35f0fa9d/attachment.sig>;