Re: [Rift] RIFT fingerprint coverage

[Antoni Przygienda <[e-mail]>]

So dropping the "burden of proof" logical fallacy @ the end ;-) the only effect right now is to increase the difficulty of the implementation without a known attack if you access those fields without checking fingerprint first anyway. I can only imagine a very far fetched attack where someone is recording another version, matching up nonces and then wait for a major protocol version change and change version on old recordings to attack. Again, most likely as likely as age of universe to happen ;-)

Looking for more opinions ...

--- tony


________________________________
From: Bruno Rijsman <[e-mail]>
Sent: Sunday, July 21, 2019 12:03 PM
To: Antoni Przygienda <[e-mail]>
Cc: Tony Przygienda <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: RIFT fingerprint coverage



On Jul 21, 2019, at 4:22 PM, Antoni Przygienda <[e-mail]<mailto:[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

     *   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
     *   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