Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2016-06-30 📝 Original message:> Yes, this is exactly ...
📅 Original date posted:2016-06-30
📝 Original message:> Yes, this is exactly what I meant. The complexity of the proposed construction is comparable to that of Bitcoin itself. This is not itself prohibitive, but it is clearly worthy of consideration.
>
> A question we should ask is whether decentralized anonymous credentials is applicable to the authentication problem posed by BIP151. I propose that it is not.
>
> The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker.
BIP151 would increase the risks for MITM attackers.
What are the benefits for Mallory of he can't be sure Alice and Bob may
know that he is intercepting the channel?
MITM is possible today, it would still be possible (though under higher
costs) with BIP151.
With BIP151 we would have the basic tool-set to effectively reduce the
risks of being MITMled.
IMO we should focus on the risks and benefits of BIP151 and not drag
this discussion into the realm of authentication. This can and should be
done once we have proposals for authentication (and I'm sure this will
be a heated debate).
The only valid risk I have on my list from you, Eric, is the false sense
of security.
My countermeasure for that would be...
- deploy BIP151 together with the simplest form of authentication
(know_hosts / authorized_keys file, no TOFU only editable "by hand")
- make it more clear (in the BIP151 MOTIVATION text) that it won't solve
the privacy/MITM problem without additional authentication.
Or could you elaborate again – without stepping into the realm of
authentication/MITM (which is not part of the BIP or possible already
today) – why BIP151 would make things worse?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160630/ddefb09d/attachment.sig>;
📝 Original message:> Yes, this is exactly what I meant. The complexity of the proposed construction is comparable to that of Bitcoin itself. This is not itself prohibitive, but it is clearly worthy of consideration.
>
> A question we should ask is whether decentralized anonymous credentials is applicable to the authentication problem posed by BIP151. I propose that it is not.
>
> The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker.
BIP151 would increase the risks for MITM attackers.
What are the benefits for Mallory of he can't be sure Alice and Bob may
know that he is intercepting the channel?
MITM is possible today, it would still be possible (though under higher
costs) with BIP151.
With BIP151 we would have the basic tool-set to effectively reduce the
risks of being MITMled.
IMO we should focus on the risks and benefits of BIP151 and not drag
this discussion into the realm of authentication. This can and should be
done once we have proposals for authentication (and I'm sure this will
be a heated debate).
The only valid risk I have on my list from you, Eric, is the false sense
of security.
My countermeasure for that would be...
- deploy BIP151 together with the simplest form of authentication
(know_hosts / authorized_keys file, no TOFU only editable "by hand")
- make it more clear (in the BIP151 MOTIVATION text) that it won't solve
the privacy/MITM problem without additional authentication.
Or could you elaborate again – without stepping into the realm of
authentication/MITM (which is not part of the BIP or possible already
today) – why BIP151 would make things worse?
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160630/ddefb09d/attachment.sig>;