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

Martin Thomson <> Mon, 04 January 2021 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2F983A177C; Sun, 3 Jan 2021 22:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=FuTt2fzg; dkim=pass (2048-bit key) header.b=q9TP5tIN
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y_OJVHQJG0fY; Sun, 3 Jan 2021 22:38:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0B7B3A174E; Sun, 3 Jan 2021 22:38:37 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id B95B21D08; Mon, 4 Jan 2021 01:38:36 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Mon, 04 Jan 2021 01:38:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=wT1tLKM54pTZrZBO437qKEnNpeIS ekmaqxAv7dYNGsQ=; b=FuTt2fzgc8X0WcZafGOHsB2rxlJ/egJsexRqOPJVW+yZ 6jqhqbA+inY9a39c+YWEQeMxN4uHWf5W56DMxxHwUqb929B1R8U6Bz/eei9M00o8 +0ZuFcY77CCHA5V0YgXBlMHaNpJ6ahTJZqTIADGL6DeegSDWfewp+xh6DL7e6Ue6 kLoIKD2j+CqgBt0lk3OwF9QOWe/B4pQOrNvNukkZ52N1d1+3jUXN46oLYSHGoGSb Rjpczr/8jMPz7nMQmB0s77S+PfcumNrgoZshFCqTuK0rW5Et/+eqJdfJCKxdGJTR sPoJpfPqm+LMrOndYvC5vMNQcfz1MZ4YTrEPT4OZDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wT1tLK M54pTZrZBO437qKEnNpeISekmaqxAv7dYNGsQ=; b=q9TP5tINRmZt6DRtKxoLhY fwC+98WqIHBHnsdlPa95OFgAHfIEEG4jWqVGB7DV9QObChULZOObPvUNpY168Y+o S+yVY5vobfbptwfhe8iL3FLZgg/89JFzVlzlKQibPz6slktnxGR15E8vmPyZixEe HQJl/eq8WR6ONa9tbhOvC4wRE03QgEex1Hy7F0mbIb3IzEztku0od/ydbEBRTh7X Ay3Fr/xmog8jmzYsunC7sGU6mbKf50pX6j0sOmr5jTEWRcFMCBBTc3xtuTy2QojN S8MphqEh/rSbbkH1JMtZ/K5gaI34+IzQwqHnUlMCiXMcfTpeXTYBXLn/hK4F0D1A ==
X-ME-Sender: <xms:7LfyXxd3BDrauXlXx6jrt_Bg6EGhC7cjq8Jl7WjpUn2BstYNeCAwVA> <xme:7LfyX_N6D7oAPnE76U2txO_NIDfsTQPCGZXdUu3O88yPevjGVgG-TZR_gWe7XgzvR vMgqfefTUxG9xHYd7g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefvddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepheefteduudduhedtkefhvdfhteelffdujeegjeffheffveekudei gfeuveekfeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:7LfyX6gDciq0ESQGQ42A2Xhm33HfpPeB7sVHYFykpKD2NnmfKobDkA> <xmx:7LfyX6_ql9UCt7qTfP_mQK9NRMILZHBQBfiKkbBlXxGiACaCnnpnDw> <xmx:7LfyX9vqH8ayu2bHMzOYMrkp5MnKZTFVVthrnBqWy5igCtrCcdmDlg> <xmx:7LfyX-X8-ZrXaW5XwZ0BejrnT6TeXwVQeuu6Y7AkZpfVlqU-nJxxmA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0CA2920120; Mon, 4 Jan 2021 01:38:36 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 04 Jan 2021 17:38:15 +1100
From: Martin Thomson <>
To: Joseph Salowey <>
Cc: 'Benjamin Kaduk' <>, "<>" <>, EMU WG <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] [Emu] 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: Mon, 04 Jan 2021 06:38:48 -0000

On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote:
> [Joe] I'm not sure I remember correctly, but I think the commitment 
> message was to make the integration with EAP statement machine cleaner 
> and perhaps to future proof against additional messages sent after the 
> handshake.  I tend to agree that the value is low in the current 
> situation (It is a deviation from RFC 5216).   Given all the discussion 
> this message has caused I'm tempted to agree that we should just remove 
> it (or make it "optional" in case implementations already do this).  
> There may need to be some text in the draft that says the 
> NewSessionTicketMessage must be sent in the same flight as the finished 
> message. I'd like to understand if there is an implementation 
> consideration that requires the commitment message.   

That might be possible, but many implementations won't be happy with that requirement.  Some implementations, particularly those that use tickets rather than server state, can't send NewSessionTicket until they have the client Certificate.

> > # 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.
> > 
> [Joe]  I can see your point, but I don't think the way the keys are 
> derived is wrong and don't really see the need to change it at this 
> point.  

Depends on what you consider "wrong".  In TLS, we did this so that you could exercise good key hygiene.  If you are backing this with PKCS#11, then you might prefer not to be exporting the value of keys just so that you can do some slicing and then re-import the same value.  I see no reason that EAP would be above this.

> [Joe] yes, however I think the agreement during the chartering was that it would 
> just update and not obsolete RFC 5216. 

Given the magnitude of the change, I don't see what this gains you other than a document that is really hard to use.