[TLS] Truncated HMAC: what to do with the MAC key?

"Andreas Walz" <andreas.walz@hs-offenburg.de> Fri, 07 July 2017 14:25 UTC

Return-Path: <andreas.walz@hs-offenburg.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99372131489 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 07:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de
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 s-8dQHKvm8Xd for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 07:25:36 -0700 (PDT)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26F112EC23 for <tls@ietf.org>; Fri, 7 Jul 2017 07:25:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id CB60522C0733 for <tls@ietf.org>; Fri, 7 Jul 2017 16:25:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:references:subject :subject:from:from:date:date:x-mailer:message-id:received :received:received; s=default; t=1499437533; x=1500301534; bh=ch FyCPvv4eMMDMHMZXHBSaKSqQtaAtZw7EpTWqH7Rug=; b=LK6T5GEdNDjoxPAIr+ BDlUJ7N5Ik9nWIyFNoheiSRknBrMUU3vwTnmcV3QWin2Oh+XpjAQszbOmPZJrf9X 7qS1nMs5l/25IhgDWlIfc+zyM9vKCEuzn8Ybm6VJ0MaJirBAsNXiYdNZhXw7kOYv cDZ6w40qtSxLgWHfQ48Bm5yo0=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBcgHVuRrfGu for <tls@ietf.org>; Fri, 7 Jul 2017 16:25:33 +0200 (CEST)
Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 0907D22C072E for <tls@ietf.org>; Fri, 7 Jul 2017 16:25:33 +0200 (CEST)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Fri, 07 Jul 2017 16:25:32 +0200
Message-Id: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2
Date: Fri, 07 Jul 2017 16:25:30 +0200
From: Andreas Walz <andreas.walz@hs-offenburg.de>
To: tls@ietf.org
References: <595F99DA020000AC00136830@gwia2.rz.hs-offenburg.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3D0536CA.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r0chP3Xb4sFDIrKyXhVdR8Lnyvw>
Subject: [TLS] Truncated HMAC: what to do with the MAC key?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 14:25:39 -0000

Dear all,

today I encountered something that confuses me: different TLS
implementations do not seem to agree on how to implement truncated HMAC.
All implementations I tested truncate the HMAC output correctly, but
they seem to use different MAC keys. When truncated HMAC is negotiated:

-> MatrixSSL does not change the length of the MAC key but zeros all its
bytes beyond index 10,
-> mbedTLS truncates the MAC key to length 10,
-> WolfSSL does not touch the MAC key at all.

>From RFC 6066 I would infer that the MAC key should not be affected by
the negotiation of the truncated HMAC extension (as WolfSSL is
implementing it). Is that correct?

Thank you very much!
Cheers



___________________________________

Andreas Walz
Email: andreas.walz@hs-offenburg.de

Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Homepage: http://ivesk.hs-offenburg.de/

University of Applied Sciences Offenburg
Offenburg University of Applied SciencesOffenburg University of Applied
SciencesOffenburg University of Applied SciencesOffenburg University of
Applied Sciences



Badstraße 24
77652 Offenburg
Germany