To: Eric Voskuil <eric@voskuil.org>, Alfie John <alfie@alfie.wtf>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
	<20160629111728.GO13338@dosf1.alfie.wtf>
	<2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57750EAB.3020105@jonasschnelli.ch>
Date: Thu, 30 Jun 2016 14:20:59 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
	Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n
Content-Type: multipart/mixed; boundary="lEoPt8M1HKDxM31sKvULuUr9vnFEusoMd"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Eric Voskuil <eric@voskuil.org>, Alfie John <alfie@alfie.wtf>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <57750EAB.3020105@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP 151
References: <87h9cecad5.fsf@rustcorp.com.au>
 <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
 <577234A4.3030808@jonasschnelli.ch>
 <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
 <20160629111728.GO13338@dosf1.alfie.wtf>
 <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>
In-Reply-To: <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>

--lEoPt8M1HKDxM31sKvULuUr9vnFEusoMd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


> Yes, this is exactly what I meant. The complexity of the proposed const=
ruction is comparable to that of Bitcoin itself. This is not itself prohi=
bitive, but it is clearly worthy of consideration.
>=20
> A question we should ask is whether decentralized anonymous credentials=
 is applicable to the authentication problem posed by BIP151. I propose t=
hat it is not.
>=20
> The core problem posed by BIP151 is a MITM attack. The implied solution=
 (BIP151 + authentication) requires that a peer trusts that another is no=
t an attacker.=20

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 =96 without stepping into the realm of
authentication/MITM (which is not part of the BIP or possible already
today) =96 why BIP151 would make things worse?

</jonas>


--lEoPt8M1HKDxM31sKvULuUr9vnFEusoMd--

--DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXdQ6rAAoJECnUvLZBb1PsOmQQAIsUmxoGwlEc03UsQdJ16KP3
vYfP3idXWb7hQOa5YzSOTF5N07jK9HZO3MCKRPIHQadH1nlPDYSb0GOESUpik2rE
peTi1H+3RlE/V3DHlE7IWUvpGAnIl/q8iUJpuwuqOc60QFKRjk2NeM7SqXToREvu
TMNTtlqpHvmRXAp+m3zt7BiUhx2XbXHvjUpZgZhvuqRbMa/NC3VWJOdTLGa3yYC0
9t8Estvba4pM6SoIVKh4wthJDaPYMpNvY6JH1AgTAnLPvkoOtKV3fC6I8N9O+OUs
f0Wg3X9sA5uUgyV6SD1nQLXLXLRGi0dy5wXFGoegdJdghRZLeOoZSq4oMAqZ0/AZ
iT/JAMHfv/dYKEiplUImhsa+PIQf69d3Jwzf0/l0tNGEeSymLkL2CaGgIkLbYnTl
6zW0z1/7cDkJS/dnnKGcI/OL1i8tF5AlNf3H3kSo6bBF4p9jd18PERVsQWDDpY7s
ATt4ynKZWgoj46isekS65DuySWTsrbJ2hq5ZeZMwVjtZYvDzWPn7IOF0QwOM2zQf
AofIKIdAAVUbhyP4NQ+BuTJN8DKBohlajErsinIlJ4fpx38GqEzmeOg9P8gkPn9w
LSNHvPE/jxefKM0IwnIoKvHcBjwVy6KMUBXBHHM9ZcuSkDVAHktHggpRYiSQhS4g
yFb6+gcXwJoiS7y7DCjN
=S8AA
-----END PGP SIGNATURE-----

--DR2EEdK3q1xfeDKeGSJAAEV9V2xNcQ24n--