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

Martin Thomson <mt@lowentropy.net> Mon, 04 January 2021 23:27 UTC

Return-Path: <mt@lowentropy.net>
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 311A33A0AC4; Mon, 4 Jan 2021 15:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=N3XFtrqy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jWbwsWJ1
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 jdKBy5NzV_Qx; Mon, 4 Jan 2021 15:27:02 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81693A0ABE; Mon, 4 Jan 2021 15:27:01 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BEC0A5C0072; Mon, 4 Jan 2021 18:27:00 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 04 Jan 2021 18:27:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=IS9sAUQitluL1P+1sM/39hdfI0sF XyLduwuP3xTxHIA=; b=N3XFtrqyx9YNnZ8aZaYw7W3hq/fWrvB4H69UEjlIG5Ej 5v+CmlReCwv65Ul1djKK+l37U3qnPNTZuGrUzpHRfDCnupCELlOTa8TAEhZ/VtUB QWdTXnI8+jCTCxOnCDAeCnnR1C9TEgV9p7jLHVyzNfm4g9mM+Yzg+at1X4IDutXi 4bRDLDW6ukgsMEG1JfD8DFBm3Pd0PMQm5qwWi9QXahf+5nEd9hQw0h18dFpYJXjt MzLbEP7K+GjVXL0O/O8ODH6OnnPUZGFZT1pxKoGvla+SieHMYBQIdaAbXVw54sxK s5sxiKl8sHwE9dzRMKBi8b28oWm6RLorHQQAoJdfNA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=IS9sAU QitluL1P+1sM/39hdfI0sFXyLduwuP3xTxHIA=; b=jWbwsWJ19NpEJcFKthl50i P09iBsJ1A2oHMcoHrqpa6RKyZtrUKLvUr4iOgBx2Me23HhI71hMlVe71VsppOwDj N5123rdoNEbBaWyfpwadg9gggB26zEod/pAld0pICtkgK3eRjP02+CE63LryIpvN LLM04S2h2f7piQ8ue8sMCpiPxdTmoOJa3EgI+c1OGz5A6MpXXVyuzhVPmpzYQWOw r12aFt2pLM+SrVFpMRb7B7216W6OmFIAf9rQ4ejVdA0Qjm3XYkymi/VO5eYak9yu FTdNmm1MziCzGRckzWZwwOMePByP2ldbA3X8cojwdr3x2gByiuQrJS8YgorGXqcg ==
X-ME-Sender: <xms:RKTzX4sVZuyZZDuE7-ckFkdTD0T0bJAgVThQa7RT1V6o5MQnh6TuHg> <xme:RKTzX1cq7AzdUUvx4PlpF9BAj9kp8IzWTnvm4EVpFcP9Tfd9T6hE84YkfUe9kky6t 0aHEW4OfnZjhQ1ClE4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefgedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepleefudfgleegiefgueevledujeejuedtleegvdetheeuvefhvdeh gfegueffiedvnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhn vght
X-ME-Proxy: <xmx:RKTzXzyJLCAoad0ek6MoTmAwxnrybLLUU6ROwLUwqlU6-WnI8U_ztg> <xmx:RKTzX7PCdYaUxrtnXCKi3ijtVgDFdmqLk-oCDaVsFfCnqQHu2OIoig> <xmx:RKTzX498WAADsflYzMYx093fgCWSwFH21mYXoXsJNLkK5jgALBhhHg> <xmx:RKTzX2lRUeVzcvofgg7mdf1pI-YN8G2oR4ikn3PACq0tNqx1EFRZ2g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C3DF2017B; Mon, 4 Jan 2021 18:27:00 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <bddc3a92-acd1-46cc-84ad-aea013c544cf@www.fastmail.com>
In-Reply-To: <7745bb87-a946-c739-007d-9d3be1212e19@ericsson.com>
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com> <7745bb87-a946-c739-007d-9d3be1212e19@ericsson.com>
Date: Tue, 05 Jan 2021 10:26:40 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>, 'Benjamin Kaduk' <kaduk@mit.edu>, "tls@ietf.org" <tls@ietf.org>
Cc: "emu@ietf.org" <emu@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ld4RfyK8VpePQ0SMW5Uh6yBAGlU>
Subject: Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
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." <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: Mon, 04 Jan 2021 23:27:03 -0000

On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote:
> >  I have a much simpler one: the EAP layer has a signal that the 
> >  protocol is complete: EAP-Success 
> Alan Dekok explained in a separate email thread why this is not the 
> case 
> (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  i.e. they are 4-bytes of data which can be spoofed rather trivially.". 

I specifically addressed that point in my original email.  My assertion was that this is not an significant concern.

Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 and while it says "A peer MUST allow for this circumstance as described in this note.", I see no explanation of how to concretely make that allowance.  Are you saying that EAP methods don't really use EAP-Success and condition their behaviour on other signals?  For TLS 1.3, where the server indicates success before the client, I can see how you might want a reliable confirmation that the server has accepted the client Finished.

As an aside, this makes is clear that the signal does not exist for the reason implied by the draft.  It does not exist to signal that the TLS messages are done; it exists to signal that the server has received and accepted the client Finished.  To that end, it's not really a layering violation in the sense that Ben describes.  The layering violation exists only because of the language constraining what TLS does thereafter; in that case, a language cleanup might be enough to address the concerns.

Note however, that the proposed design does not guarantee that a Confirmation Message acknowledges the client Finished.  The server can send the proposed Confirmation Message before the client completes the handshake.  

Echoing the client Finished might help, but that's a layering violation too.  Ideally you would be able use something like exporters to help, but those have problems (see below).  I know it's a knee-jerk, but the idea of making EAP-Success reliable is far more appealing to me than anything you suggest.
 
> I also think that this should not be treated as an issue for EAP-TLS 
> only. I can imagine other deployments which use TLS for making 
> authorization decisions but do not use the TLS for sending message. So 
> I am glad that Ben has brought this to the TLS working group for 
> further discussion. Whether we use this 1-byte of application data (as 
> done in this draft) or some other mechanism (such as close_notify), we 
> need a reliable way of telling that no further post handshake messages 
> will be sent. 

EAP has the privilege of being the first to grapple with this.

I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not the ideal design.  They should have included the full handshake transcript, just like the resumption secret.  There were good reasons at the time for designing them as they are, and there are likely reasons to retain the current design as an option (it's stronger than the early exporter and there might be use cases), but those original reasons are less relevant.  The current design gives short shrift to client authentication, to the detriment of use cases like EAP.

Having exporters depend on the entire transcript would serve EAP better.  In this case, you could provide an application-level signal using an exported value.

Without that sort of in-TLS affordance, confirming receipt of the client Finished might do.  You still have the possibility that the server doesn't depend on client authentication and so predicts the value, but that would be true of a full-transcript exporter too, so arguably that doesn't matter.