[bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution with ERIS

[pukkamustard]

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> Is it possible for the following situation to happen?
> If so, why not?
>
>   1. server A is authentic
>   2. server M is malicious, it tries to trick the client into
>      installing an incorrect substitute
>   3. (key of) server A is authorised
>   4. (key of) server M is _not_ authorised
>   5. server A and M are both in substitute-urls
>   6. server A only serves ‘classical’ substitutes, server B also serves
>      via ERIS+ipfs
>   7. Both A and M set the same FileHash, References, etc. in the
>      narinfo
>   8. However, M set an ERIS URN pointing to a backdoored substitute.
>   9. The client trusts A, and A and B have the same FileHash etc.,
>      so the client considers the narinfo of B to be authentic
>      because it has the same FileHash.
>  10. The client prefers ERIS above HTTP(S), so it downloads via M.
>  11. The client now installed a backdoored substitute!
>
> Greetings,
> Maxime.

No this should not work.

The ERIS URN is only used if the entire narinfo is signed with a
authorized signature. The FileHash is not used when getting substitutes
via ERIS (being able to decode ERIS content implies integrity).

The interesting case that would be allowed with ERIS is following:

1. Server A is authentic and its key is authorized.
2. Servers M1 to MN are potentially malicious and their keys are not
   authorized.
3. Server A and servers M1 to MN are in the substitute-urls.
4. Client gets Narinfo from server A and uses the ERIS URN from there.
5. Client can get blocks simultaneously from Server A and servers M1 to
   MN.
6. Client decodes content with the ERIS URN and can be sure that they
   have the valid substitute.

So client only needs to trust A but can use M1-MN (simultaneously) for
fetching the content.

-pukkamustard