BIP 151 MITM

> Hi folks,
>
> Overall I think BIP 151 is a good idea. However unless I'm mistaken, what's to
> prevent someone between peers to suppress the initial 'encinit' message during
> negotiation, causing both to fallback to plaintext?
>
> Peers should negotiate a secure channel from the outset or backout entirely
> with no option of falling back. This can be indicated loudly by the daemon
> listening on an entirely new port.

> Reduction to plaintext isn't an interesting attack vector for an active
> attacker: they can simply impersonate the remote side.
>
> This is addressed via authentication, where available, which is done by a
> separate specification that builds on this one.

> On Thu, Jun 09, 2016 at 01:24:09AM +0000, Gregory Maxwell wrote:
>> Reduction to plaintext isn't an interesting attack vector for an active
>> attacker: they can simply impersonate the remote side.
>>
>> This is addressed via authentication, where available, which is done by a
>> separate specification that builds on this one.
>
> Are there any links to discussions on how authentication may be done?

> > Are there any links to discussions on how authentication may be done?
>
> I'm currently working on the Auth-BIP which is not worth reviewing it
> right now (I will post it to the mailing list once it has been reached a
> stable level where it can be discusses).
>
> If you can't wait, here is the current work:
> https://github.com/jonasschnelli/bips/blob/35d7e382cdd6955ff42726c3d06c44e33f61ae52/bip-undef-0.mediawiki
>
> Most recent MITM/auth discussion (there where plenty of discussions on
> IRC about this topic):
> https://botbot.me/freenode/bitcoin-core-dev/2016-04-04/?msg=63463826&page=3