Re: [Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15

[Alexander Clouter <[e-mail]>]

On Sun, 3 Mar 2024, at 15:52, Alan DeKok wrote:
>> If not, then in theory a MITM might be able to remove the last
>> server-to-peer outer TLV and prepend it to the peer-to-server TLVs, or vice
>> versa, and the MAC would be the same. However, each side knows which outer TLVs
>> it sent before the MITM modified it, so I don't think this could accomplish
>> anything in practice?
>
>   The server calculates the compound MAC using the outer TLVs it sent, 
> and the outer TLVs it received from the peer.
>
>   The peer calculates the compound MAC using the outer TLVs it sent, 
> and the outer TLVs it received from the server.
>
>   As a result, and modification in transit is detected, because the 
> compound MAC will not be the same.

Took me a moment to figure out what David was pointing to but I think you are incorrect.

In Section 5.3 (Computing the Compound MAC), you are calculating the MAC through blind concatenation and there is no machinery in there to distinguish "this bit was in the server->peer" and "this bit was in the peer->server"; unfortunately if only a NUL byte has been used to join the concatenation it could have fixed this.

So the idea is an attacker could strip off the *last* Outer-TLV and instead graft it as an Outer-TLV to the following packet in the opposite direction. The MACs would then match.

My proposal would be to just use a dummy (marked optional) Outer-TLV that would be ignored by the other end to avoid this problem; sort of like GREASE...but to fix an insecurity instead.

Cheers