Subject: Re: [multipathtcp] ADD_ADDR HMAC ambiguity
From: Alan Ford <[email-masked]>
To: Christoph Paasch <cpaasch=[email-masked]>
Cc: MultiPath WG <[email-masked]>, mptcp Upstreaming <[email-masked]>, Todd Malsbary <[email-masked]>
Date: Wed, 20 May 2020 21:38:18 +0100
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>

Hi Christoph,

Your interpretation is the intended one.

3.4.1 says "rightmost 64 bits of an HMAC” … the HMAC is 256 bits in both 3.2 and 3.4.1. The truncation is the separate from the definition of the HMAC algorithm used.

Best regards,
Alan

> On 20 May 2020, at 17:40, Christoph Paasch <cpaasch=[email-masked]> wrote:
> 
> Hello,
> 
> Todd Malsbary from Intel is looking at the HMAC-support for ADD_ADDR in
> RFC8684. And it appears that there can be an ambiguity on how to interpret
> the truncation.
> 
> We want to clarify this and make sure all implementations,... are on the
> same page with the intention of the RFC:
> 
> RFC8684, Section 3.4.1 says:
> " The Truncated HMAC parameter present in this option is the rightmost
>  64 bits of an HMAC, negotiated and calculated in the same way as for
>  MP_JOIN as described in Section 3.2. "
> 
> Now, in Section 3.2 it mentions:
> " This specification defines that HMAC as defined in [RFC2104] is used,
>  along with the SHA-256 hash algorithm [RFC6234], and that the output
>  is truncated to the leftmost 160 bits (20 octets). "
> 
> 
> One can read these in two different ways:
> 
> In Section 3.4.1, the truncation to the rightmost 64 bits is based on the
> full 256-bit HMAC-output or whether it is rather the 64 rightmost bits of
> the leftmost 160bits (the ones mentioned in Section 3.2).
> 
> 
> Can we clarify which of the two options is the correct one?
> 
> 
> 
> I personally interpret it as "right most 64 bits of the 256-bit HMAC-output".
> 
> 
> 
> Thanks,
> Christoph
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp