Re: [radext] WGLC for draft-ietf-radext-tls-psk-04

Alan DeKok <aland@deployingradius.com> Tue, 23 January 2024 12:08 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449AAC14F6F2 for <radext@ietfa.amsl.com>; Tue, 23 Jan 2024 04:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 5RiT9bkupddi for <radext@ietfa.amsl.com>; Tue, 23 Jan 2024 04:08:19 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 E8147C14F6EC for <radext@ietf.org>; Tue, 23 Jan 2024 04:08:18 -0800 (PST)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 450F62F1; Tue, 23 Jan 2024 12:08:15 +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 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <ae25fac9-47c1-4f00-a655-75d4dd2034fa@dfn.de>
Date: Tue, 23 Jan 2024 07:08:13 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF7AC8CE-098C-4BE8-9676-14C333711BCC@deployingradius.com>
References: <005901da242e$f623d550$e26b7ff0$@smyslov.net> <6172ba00-6793-4393-9466-37b52fe1e25b@switch.ch> <651E26F6-B0B2-40A7-B636-88569CFEFCB3@deployingradius.com> <e34c5a26-079d-4988-83b0-c53c3708ef2e@switch.ch> <57B035CF-64CA-4B93-9FEE-929D7DD80D32@deployingradius.com> <3af70e7f-356e-4d49-a1a0-a4c6d270a1a3@switch.ch> <89087622-6499-4B64-8139-75D4464B49A2@deployingradius.com> <02F27A5D-33AD-4B35-BF46-716345E480CA@deployingradius.com> <fa3138fb-875b-409f-814a-ef02d612ce20@dfn.de> <3956CC37-4E8A-4041-8C40-387E8F598237@deployingradius.com> <ae25fac9-47c1-4f00-a655-75d4dd2034fa@dfn.de>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/JhRj7JHlgDO3zXNh1NMTgpUsnbQ>
Subject: Re: [radext] WGLC for draft-ietf-radext-tls-psk-04
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2024 12:08:20 -0000

On Jan 23, 2024, at 4:25 AM, Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
> The thing that is currently inconsistent between the radius-dtls-bis and the TLS-PSK draft is the requirement to implement TLS-PSK.

  We can always update TLSbis to be in agreement with TLS-PSK.

> The RADIUS/(D)TLS draft says servers MUST, clients can choose between TLS-PSK and PKIX.
> This was the result after the consensus call after IETF 117.

  There was also a consensus call for TLS-PSK which came to the opposite conclusion.  The WG is imperfect.

> Again, I am not opposed to change the wording in the RADIUS/(D)TLS draft, but this should be a decision of the WG. I haven't seen any response from other WG members.
> 
> We should definitely bring this up at the IETF119.

  I agree.

  Alan DeKok.