Issue with no_hmac_verify flag about babeld HOT 6 CLOSED

(#52)

from babeld.

the goal is not to skip checking but rather ignore when there's no HMAC.

What difference does it make to reject incorrectly-signed packets?

On a side note, my code e314264 is probably wrong. The name babel-mac-verify comes from the Information Model.

from babeld.

the goal is not to skip checking but rather ignore when there's no HMAC.

What difference does it make to reject incorrectly-signed packets?

The issue is that correctly-signed packets are rejected.

I have the feeling to have said everything, but I can try to explain differently. Let's given 3 kinds of nodes:

1. nodes without any hmac-related option given to babeld command-line
2. nodes with hmac configured with 1 key, and some whatever flag (no_hmac_verify, hmac_verify, ignore_no_hmac) at a non-default value
3. nodes with hmac configured with 1 key and the flag at a default value

We expects that:

1. nodes 1 can communicate with nodes 2
2. nodes 2 can communicate with nodes 3
3. nodes 1 can not communicate with nodes 3

#35 verifies the above 3 cases. The hmac branch of jech/babeld (91a9259) fails for case 2.

Otherwise, what would be the purpose of the discussed flag if it's not to provide a way to do a smooth upgrade to using HMAC ?

On a side note, my code e314264 is probably wrong.

Oops, I didn't notice that #52 has more commits than the hmac branch of jech/babeld. We use the latter.

About e314264 I don't see any code initializing hmac_verify to the default value of true.

from babeld.

Your presentation with the three kinds of nodes is very clear, thanks.
I applied (b909a58) your commit with some minor changes into my branch (#52).

About e314264 I don't see any code initializing hmac_verify to the default value of true.

Thanks, fixed in 7b79301.

from babeld.

I'm sorry if I'm daft, Julien, but I still don't understand.

The intent of the old code is that no HMAC verification is made at all if NO_HMAC_VERIFY is set. In other words, HMACs are ignored on reception, unconditionally. This is a simple semantics, and one that's easy to explain.

It looks like the code is buggy; that's possible, in which case I'll be grateful for a bugfix.

Your patch, however, changes the logic: now unsigned packets are accepted, but incorrectly signed packets (e.g. packets signed with an obsolete key) are rejected. This is a complicated semantics, one that is not easy to explain, and one that I don't feel is useful.

Would you be willing to provide a fix for the bug without changing the intent of the code?

from babeld.

The flag is now called accept-bad-signatures, and causes the interface to accept both unsigned packets and packets with an incorrect key. Rejecting the latter provides no additional security, since an attacker can simply send unsigned packets.

Please let me know if there's still something missing.

from babeld.