Re: [Rift] RIFT fingerprint coverage

[Tony Przygienda <[e-mail]>]

I think we misunderstood. If you validate things _before_ a fingerprint
(which we have here, without lenght in front of fingerprint we don't know
where to find it) you normally compute the fingerprint over empty
fingerprint & you have to validate the same way. This is normally the place
where problems occur due to unusal logic necessary in the right sequence

I agree, the discussion is is there an attack worth doing the extra work, I
don't see one + as I say we not really protect anything since we access the
fields before fingerprint anyway and any change, if not failing before
fingerprint will make fingerprint invalid anyway ...

--- tony


On Sun, Jul 21, 2019 at 12:04 PM Bruno Rijsman <[e-mail]>
wrote:

>
>
> On Jul 21, 2019, at 4:22 PM, Antoni Przygienda <[e-mail]> wrote:
>
>
>
> 3. second, even if we do I don't think we improve the attack envelope or
> actually worsen it. Let's go through it
>
>    1. major version is attacked, any change will drop the packet due to
>       mismatch. if we protect it, we calculate the hash and it fails and outcome
>       is the same modulo we can be computationally overrun
>       2. outer key id is attacked/fingerprint length is attacked, all
>       same outcome ...
>
> now, you can argue that an attacker can modify stuff _behind_ the
> fingerprint and with that attack protocol computationally but there is no
> way around that, we won't detect modification otherwise wheeras modifying
> major version/key id/fingerprint lenght basically leads to drops on any
> change and protecting them only exposes us computationally for no benefit
>
>
> The receiving RIFT router can drop packets with the wrong major version,
> with a wrong key-id (not in the accept key set), or a wrong
> fingerprint-length, *without* validating the fingerprint first.
>
> This is for the same reason that a RIFT router can drop a packet with an
> out-of-range weak-nonce *without* validating the fingerprint first.
>
> In general, it is safe to reject a packet when any field has some
> unacceptable value *without* validating the fingerprint first.
>
> So, protecting these additional fields does not open up any new CPU denial
> of service attacks.
>
> If a RIFT router is planning to accept a packet because all fields have an
> acceptable value, then it must validate the fingerprint first before doing
> so.
>
> Or if a RIFT router is going to reject a packet but take some protocol
> action based on some field in that rejected packet anyway, then it would
> have to validate the fingerprint as well (happily, which currently don’t
> have this scenario in RIFT, as long as the packet-nr is truly only used for
> debugging and not for flow-control, for example).
>
> So, the real question is: how sure are you that leaving the major-version,
> key-id, and fingerprint-lengths fields unprotected will not lead to some
> problems down the road?  (To quote Dirty Harry: “Do you feel lucky? Well,
> do ya, punk? :-)
>
> — Bruno
>
>