Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

Alan DeKok <aland@deployingradius.com> Mon, 04 March 2024 18:56 UTC

Return-Path: <aland@deployingradius.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 3A533C1654EF for <emu@ietfa.amsl.com>; Mon, 4 Mar 2024 10:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nom13Oc1gnis for <emu@ietfa.amsl.com>; Mon, 4 Mar 2024 10:56:00 -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)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD8CC13AE21 for <emu@ietf.org>; Mon, 4 Mar 2024 10:55:59 -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 BA8CB308; Mon, 4 Mar 2024 18:55:57 +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: <523cd040-7485-4968-8367-4a6c274a284c@uni-bremen.de>
Date: Mon, 04 Mar 2024 13:55:56 -0500
Cc: emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1865CE66-3B4F-4A10-96BC-49CEE9E0D78C@deployingradius.com>
References: <170932527085.22824.18343512124707075119@ietfa.amsl.com> <66bca1b2-4b2d-429d-8f85-5c76d29005ad@dfn.de> <c2951f3d-bcc7-4b90-bcdd-077a506dd464@app.fastmail.com> <523cd040-7485-4968-8367-4a6c274a284c@uni-bremen.de>
To: Jan-Frederik Rieckers <rieckers@uni-bremen.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/v6qKGC4eK9ThkpMrPN8sJpDlNVk>
Subject: Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.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: Mon, 04 Mar 2024 18:56:01 -0000

On Mar 3, 2024, at 7:57 AM, Jan-Frederik Rieckers <rieckers@uni-bremen.de> wrote:
> The idea here is that future versions may signal some information outside the TLS tunnel. Our first idea, where this kind of still stems from was that the server signals the RPID outside the TLS tunnel, so the client can verify that the server's certificate is in fact valid for that.

  I would strongly prefer that there be no signalling outside of the TLS tunnel.  The "outer TLV" issue with TEAP is frustrating for an implementor.  Adding similar, but different, things for other EAP methods makes implementations more difficult.

  ALPN would be much simpler, I think.  The downside there is that every time you rev the protocol, you have to register a new ALPN name.  That's annoying.  I don't know if it would be acceptable to register an ALPN _prefix_, and then just self-allocate versions.

  An alternative would be to do the version negotiation inside of the TLS tunnel.  That's also imperfect, but at least gives EAP-FIDO complete control over all aspects of the protocol.

  Alan DeKok.