[multipathtcp] ADD_ADDR HMAC ambiguity

Christoph Paasch <cpaasch@apple.com> Wed, 20 May 2020 16:40 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09CD3A09E7 for <multipathtcp@ietfa.amsl.com>; Wed, 20 May 2020 09:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUVCBCmvgNi2 for <multipathtcp@ietfa.amsl.com>; Wed, 20 May 2020 09:40:27 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798393A09BE for <multipathtcp@ietf.org>; Wed, 20 May 2020 09:40:27 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04KGUsvY026561; Wed, 20 May 2020 09:40:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=date : from : to : cc : subject : message-id : mime-version : content-type; s=20180706; bh=XIUYgMs2xyXy6OP9k5tvlRJ/mXZGIUxKkLUtJVRiB9E=; b=jx5GEzI33Tof2KPJYYYeeQVDT6Y5LSguTgEfX9ioRgvQkGxVfHVJcjwifvt6YPg51oDP +8bUHP0RDL5bvyEg94mlE7/SBGNl+/BfRmLk/IuWsORW5YUeD0Muj2MKp62r3r0frtom DNIuNYos8oxg5nEt6HN90gdxLa6X5JhG4MAlBE2mlF7X+rvHqHOTH30WbVqwBxDKLzLs PpOpgSa85oMQyoDUA588DMkz8u9F7HAaWU0smjNqlIlMgN6epvH2z4YuKFtcYEstETCE LCY++1p4jpa5U6K0f6eLBA3ZxbkCwoaIvAYHzSP7lj5ZV6PXNNAJhHyjdVnVZeSfIqC9 kw==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 312nrtx8hj-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 May 2020 09:40:26 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QAN00P3G2BCTO70@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 20 May 2020 09:40:24 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QAN00U001QUY700@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 20 May 2020 09:40:24 -0700 (PDT)
X-Va-A:
X-Va-T-CD: d9bf4ebf4e0b78ea14d96762179f43be
X-Va-E-CD: d20c14cb331db685e20d7be1e9474c2d
X-Va-R-CD: e16f702d5b5111d971f9f7f5cd6997f2
X-Va-CD: 0
X-Va-ID: 100d63eb-66a4-4fff-9aaf-3c07e2162767
X-V-A:
X-V-T-CD: d9bf4ebf4e0b78ea14d96762179f43be
X-V-E-CD: d20c14cb331db685e20d7be1e9474c2d
X-V-R-CD: e16f702d5b5111d971f9f7f5cd6997f2
X-V-CD: 0
X-V-ID: 475a65b1-2aa0-47df-a94d-a7b701e61f1e
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-20_12:2020-05-20, 2020-05-20 signatures=0
Received: from localhost ([17.235.11.110]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QAN002J42BB3Q30@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 20 May 2020 09:40:23 -0700 (PDT)
Date: Wed, 20 May 2020 09:40:23 -0700
From: Christoph Paasch <cpaasch@apple.com>
To: MultiPath WG <multipathtcp@ietf.org>
Cc: mptcp Upstreaming <mptcp@lists.01.org>, Todd Malsbary <todd.malsbary@linux.intel.com>
Message-id: <20200520164023.GH45434@MacBook-Pro-64.local>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-disposition: inline
User-Agent: Mutt/1.12.2 (2019-09-21)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-20_12:2020-05-20, 2020-05-20 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/ukLTL16rbwogqhF2CQbh_6uXtpk>
Subject: [multipathtcp] ADD_ADDR HMAC ambiguity
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 16:40:29 -0000

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