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

From: "Andreas Walz" <[email-masked]>
Date: Fri, 07 Jul 2017 16:25:30 +0200

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: [email-masked]

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Jul 2017 11:27:05 -0500

On 07/07/2017 09:25 AM, Andreas Walz wrote:
> 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,

I agree with your reading of RFC 6066 (and RFC 2104).

-Ben

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 8 Jul 2017 04:38:18 +0000

Andreas Walz <[email-masked]> writes:

>different TLS implementations do not seem to agree on how to implement
>truncated HMAC

It also says something about the status of this capability if three of the
four known implementations can't interoperate.  If it's taken fourteen years
(RFC 3546 was 2003) for someone to notice that the implementations don't
work/interoperate then maybe the capability should be marked as deprecated or
obsolete or unused or something.

Just out of interest Andreas, why were you checking this?  In other words how
did it get noticed?

Peter.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 8 Jul 2017 01:15:17 -0400

> obsolete or unused or something.

In progress; the Truncated HMAC TLS extension is prohibited in implementations that support TLS 1.3+ as of the current draft.

https://tools.ietf.org/html/draft-ietf-tls-tls13-21#page-127

Dave

---

From: "Andreas Walz" <[email-masked]>
Date: Sat, 08 Jul 2017 15:54:40 +0200

Thanks for your feedback.

One other thing I could image is that truncated_hmac is mostly used in closed systems where one and the same implementation is used on both sides. 

@Peter: We are developing software for Smart Metering in Germany where TLS is used over the (wireless) Metering Bus. The corresponding specification [1] says about truncated_hmac: "servers shall support...".

Cheers,
Andi

[1] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03109/TR-03109-1_Anlage_Feinspezifikation_Drahtlose_LMN-Schnittstelle-Teil2.pdf?__blob=publicationFile&v=1

>>> Dave Garrett <[email-masked]> 08.07.17 7.15 Uhr >>>

Dave