Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-09.txt

Alexander Clouter <alex+ietf@coremem.com> Tue, 03 January 2023 08:23 UTC

Return-Path: <alex+ietf@coremem.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827D3C14CE3C for <emu@ietfa.amsl.com>; Tue, 3 Jan 2023 00:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b=iSWL2y96; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vg8KTDGV
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpENx9Nbvh3o for <emu@ietfa.amsl.com>; Tue, 3 Jan 2023 00:23:11 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB9DC14CE38 for <emu@ietf.org>; Tue, 3 Jan 2023 00:23:10 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 602D432009B1 for <emu@ietf.org>; Tue, 3 Jan 2023 03:23:03 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Tue, 03 Jan 2023 03:23:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1672734182; x=1672820582; bh=MciulNQYjJ hkL1GCM8F9KsIJbwLuO94dgKiMv8Rlr3U=; b=iSWL2y96pux/jzWmjjvzLWvd4e r3vCQdQbOU3RjMBkz5mC5dg9+ga6F3Yz+6jXssuql5kkeBXvT367ILXVzuZ4m2al WIiLIyoYBToiDRubmddnDG9ILWT5WDm2Nraa+npOC10hFncHxobV0z6XtDsU0JQu kmZRhPXYgiZIeTd1rRkaV9pfymbfT8jf0ub+Xy3jGZirUkmXmPcyCcijUlknZiV7 XZEdVDP4GUO/vD+gW4punYzTmy/rQrST3+pCERsebvCwKLzR/otK9wZ7BcnnUTYM nw+JQf1I8nIaUUmgHwdFR4zI3ZY/YLuaSiVMLxFDzLY9vGl2KganGH7dtlrQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672734182; x=1672820582; bh=MciulNQYjJhkL1GCM8F9KsIJbwLu O94dgKiMv8Rlr3U=; b=vg8KTDGV+fnFsmiEjh3LC4BFZBBwpqumW0lIYdwXdM6T fe2JdPjqIFzTpq0/SGoCQEhRa082wKgvgj4rvXrRo3jc/GvQsftTa90cTI2SBKMA NHHNrqmgWT503v4qzP6dez4przs5kNg5mbinUgMUiXBRRGjaTl4tAxtKemwrDADY +EvrYVnsSlLPwm32WeOZJrqREmhN3EAJusa/mQyXxEhQ3cUuz9Gg1eeNfHBFU3VZ lnQJRuqDVx+y/OCh7gvw9ve27VZBUuncxbmrnACFZ1SMJ8dib4mSLEn7evr6iGBn zvDm5/+7Xg0iorb2hubMOMPd31Df+A6Ni20JFo6/MQ==
X-ME-Sender: <xms:5uWzY1blYIpp0p4OkSPRGCh7ROgHpBU8KAYoIPd0JsJ6VBlbC_zw0A> <xme:5uWzY8YFi0BTX7_x-I-dgp6l3E_vKJV1rPn0KWE4QNYkavz4EQScRzJimFMkpkjO- 7Bb05iVTz3JJjgcLQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeefgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceorghl vgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetje fhhefggeelueelfeetieekgfevhfehkeehvedvkeeufeekieeifffhvdegnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvgigodhivghtfh estghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:5uWzY3-xSWA_8HZvALDtohl0n-ql0EdfaWkUFQTaQgzolEcBojDo_g> <xmx:5uWzYzoZ0Dz7SXgS4kcvc3dPPIECro_kxdF7wRlFzj6vj1LGLW2AFw> <xmx:5uWzYwqeAKXlSa6QEdz_sOks1w0DevhSmjDuHrUPsUe4OOPt68FvGw> <xmx:5uWzY91krCCTS6nrNVYXHCy4NmTzdNzdlGzTwkvHMX6Z9iaZO2OunA>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C08082A20080; Tue, 3 Jan 2023 03:23:02 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730
Mime-Version: 1.0
Message-Id: <9a0c0e90-5683-432e-a7b8-1f45a96f4b04@app.fastmail.com>
In-Reply-To: <166428153120.54333.17278955597896126770@ietfa.amsl.com>
References: <166428153120.54333.17278955597896126770@ietfa.amsl.com>
Date: Tue, 03 Jan 2023 08:22:42 +0000
From: Alexander Clouter <alex+ietf@coremem.com>
To: EMU WG <emu@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/61anHt0OCpnKcR2cYMG9TMi9Mvo>
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-09.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2023 08:23:16 -0000

On Tue, 27 Sep 2022, at 13:25, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>   Title           : TLS-based EAP types and TLS 1.3
>   Author          : Alan DeKok
>   Filename        : draft-ietf-emu-tls-eap-types-09.txt
>   Pages           : 21
>   Date            : 2022-09-27

Whilst picking through the TEAP RFC7170(bis) section 3.2 I stumbled on:

"TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current ciphersuite."

This language looks lifted from from the EAP-FAST (RFC4851 section 3.2).

This exists so that for TLS 1.2 (and earlier) you can provide identity privacy and mutual authentication during Phase 1.

As TLS 1.3 already provides the identity privacy, I think retaining the SHOULD is a good idea for backwards compatible as well as creating minimal changes to existing implementations. I do think we should highlight in the various 'Client Certificates' sub-sections that now doing the immediate renegotiation is no longer necessary.

Thanks