Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Tue, 05 January 2021 05:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B79B3A1018; Mon, 4 Jan 2021 21:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nuMMhABKpg2X; Mon, 4 Jan 2021 21:43:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6651E3A1016; Mon, 4 Jan 2021 21:43:57 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 1055hppi005611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Jan 2021 00:43:56 -0500
Date: Mon, 04 Jan 2021 21:43:51 -0800
From: Benjamin Kaduk <>
To: Martin Thomson <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jan 2021 05:44:00 -0000

On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote:
> I would instead either prohibit the use of application data outright or say that it carries no semantics unless otherwise negotiated.  The current design has the effect of rendering application data unusable, so perhaps the former is best.

The "rendering application data unusable" bit is something that bothered me
a lot as well.  While banning application data is okay for EAP-TLS itself
(AIUI), the document implies that other TLS-based EAP mechanisms do need to
convey application data, and I think that the responsible thing to do is
ensure that the machinery we use here would be compatible with those other
EAP mechanisms with no, or only minimal, changes.

> # Key Schedule
> The other thing I observe is the way that this slices up the exporter output.  This was something that old versions of TLS did, but TLS 1.3 did away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - and should - do the same.  All it means is having more exporter labels.
> I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS exporter for each of the six values that the protocol requires.  I also note that the 0x0D value is used multiple times, unnecessarily, both as a context strong to the exporter and as a prefix to the session ID.

I think Alan explained the dual purpose of the Type-Code here.  (I myself
had missed the connection of where the 0x0d value came from, and a
reference for that seems like it would be helpful, as setting up this
machinery for reuse by other mechanisms in a way that provides key