Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

Alan DeKok <aland@deployingradius.com> Fri, 11 June 2021 14:17 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 A26173A45F4 for <emu@ietfa.amsl.com>; Fri, 11 Jun 2021 07:17:18 -0700 (PDT)
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 4of2eissCrUc for <emu@ietfa.amsl.com>; Fri, 11 Jun 2021 07:17:13 -0700 (PDT)
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 B5E8D3A4605 for <emu@ietf.org>; Fri, 11 Jun 2021 07:17:09 -0700 (PDT)
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 3B5613FF; Fri, 11 Jun 2021 14:17:06 +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.6\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <a9934d97-c01d-ad9a-bb95-f397d73e6140@ericsson.com>
Date: Fri, 11 Jun 2021 10:17:05 -0400
Cc: "emu@ietf.org" <emu@ietf.org>, Joseph Salowey <joe@salowey.net>, Roman Danyliw <rdd@cert.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3039B712-15E2-4C32-95C4-48CE5B73A0F7@deployingradius.com>
References: <162341585509.25821.12001005879203873531@ietfa.amsl.com> <fde152d8-ff88-ea03-cbad-330a302a9442@ericsson.com> <49E7E4C8-CB9C-4A96-A7E4-1EE778BD58F5@deployingradius.com> <a9934d97-c01d-ad9a-bb95-f397d73e6140@ericsson.com>
To: Mohit Sethi M <mohit.m.sethi@ericsson.com>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/ybP5I4kbpVWVZJ-xX3xvdP131IQ>
Subject: Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 11 Jun 2021 14:17:28 -0000

On Jun 11, 2021, at 9:56 AM, Mohit Sethi M <mohit.m.sethi@ericsson.com> wrote:
> 
> I guess you know that there are several implementations of the draft 
> some of which are already deployed.

   While that's a nice comment telling me what I already know, it doesn't address my point.  The fact that implementations exist does not mean that the specification is sufficient to create an implementation.

  The implementors have had many "behind the scenes" discussions about how to implement EAP-TLS 1.3.   The outcome of those discussions was shared among implementors.  That information is largely what enabled inter-operability.  Information which is not all reflected in the document.

  I have suggested repeatedly that the document contain sufficient information to create a secure and inter-operable implementation.  It's not clear to me why these suggestions have been ignored, or rejected.

> It is of course nice to strive for perfection.

  That comment misrepresents my position.

> Could you please submit a pull request addressing your 
> unaddressed comments.

  I gave suggested text in my messages.  These comments were largely ignored across multiple reviews.  This is not how we should work towards consensus.

  If the goal of this document is simply to get it published, then I withdraw all of my objections.  Implementors will then share extra knowledge behind the scenes.

  If the goal of this document is to enable secure and inter-operable implementations, then it would be useful to address comments from major implementors.

  Alan DeKok.