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

Alan DeKok <aland@deployingradius.com> Tue, 05 January 2021 15:42 UTC

Return-Path: <aland@deployingradius.com>
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 0A5FD3A105D; Tue, 5 Jan 2021 07:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9LG3KNlKjwuD; Tue, 5 Jan 2021 07:41:58 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8462A3A1065; Tue, 5 Jan 2021 07:41:54 -0800 (PST)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 17B3537F; Tue, 5 Jan 2021 15:41:51 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <2aa31d9d-0603-5c5e-de3c-0dc780516863@ericsson.com>
Date: Tue, 05 Jan 2021 10:41:50 -0500
Cc: Benjamin Kaduk <kaduk@mit.edu>, Martin Thomson <mt@lowentropy.net>, "emu@ietf.org" <emu@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBC4BCAD-1AA2-4D19-B03E-6A2D5F595509@deployingradius.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> <bddc3a92-acd1-46cc-84ad-aea013c544cf@www.fastmail.com> <5E1CF713-D917-4E9A-869F-21A4174D0562@deployingradius.com> <5ec5d8a2-a8ee-40b5-9b43-3d1bde2b0032@www.fastmail.com> <20210105052640.GO93151@kduck.mit.edu> <2aa31d9d-0603-5c5e-de3c-0dc780516863@ericsson.com>
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QwEIrf4RZ4INBA1bHOxqOEDgRdU>
Subject: Re: [TLS] [Emu] 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: Tue, 05 Jan 2021 15:42:06 -0000

On Jan 5, 2021, at 4:47 AM, Mohit Sethi M <mohit.m.sethi@ericsson.com> wrote:
> What I am gathering is that this commitment message should instead be 
> made into a confirmation message, i.e. it should only be sent after 
> receiving TLS Finished from the client? This would result in one extra 
> round trip to both figure 1 and 3 in the current draft. So we would end 
> up with the same number of messages as RFC 5216 for full authentication 
> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do 
> worse than RFC 5216 (one extra round trip) in case resumption 
> (https://tools.ietf.org/html/rfc5216#section-2.1.2).

  That sounds right.

> Maybe this is acceptable? The draft anyway notes that "Sending the 
> Commitment Message in a separate EAP-Request adds an additional 
> round-trip, but may be necessary in TLS implementations that only 
> implement a subset of TLS 1.3.". In which case, I am not sure if the 
> reasons against using close_notify apply anymore.

  I won't offer opinions on TLS internals, as I'm out of my depth there.

  As an implementor, the priority is getting TLS alerts (expired cert, etc.) back from the EAP server to the EAP peer.  Those messages can then be used to debug deployment issues.

  The exact method of doing this is less important.  The "0x00" octet works now, so I'm happy with it.  But if TLS review decides that should change, that's fine, too.

  Alan DeKok.