Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Alan DeKok <aland@deployingradius.com> Wed, 30 October 2019 11:12 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 7B6EE120099; Wed, 30 Oct 2019 04:12:06 -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=unavailable 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 LzIBsP0OnwoI; Wed, 30 Oct 2019 04:12:04 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB899120120; Wed, 30 Oct 2019 04:12:03 -0700 (PDT)
Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 4C81F66A; Wed, 30 Oct 2019 11:12:00 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <B31BF8C4-6568-49F2-BBD1-BD6AC66D393C@cisco.com>
Date: Wed, 30 Oct 2019 07:11:58 -0400
Cc: Joseph Salowey <joe@salowey.net>, "draft-ietf-emu-eap-tls13@ietf.org" <draft-ietf-emu-eap-tls13@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, Michael Richardson <mcr@sandelman.ca>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com>
References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <CY4PR1101MB22781AB8C8982ACF99B61544DB8E0@CY4PR1101MB2278.namprd11.prod.outlook.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <CAOgPGoBko6N_JebmisoSk_EJ=Hq21sV3xoXjLw4r7D+OFSsdZA@mail.gmail.com> <CC58A292-03D6-4D70-A11F-B8FEE7311E78@cisco.com> <26738.1570791861@dooku.sandelman.ca> <AD799A14-8268-4BAF-8925-3567973C7507@cisco.com> <9501.1570802988@dooku.sandelman.ca> <DCC85780-B079-4AD0-8870-7528270B70D8@cisco.com> <CAOgPGoA0RCY+J5bDOyUiKtFy5Vk=C11yvE8O=rsJPQeS8Fzk0A@mail.gmail.com> <B31BF8C4-6568-49F2-BBD1-BD6AC66D393C@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/HF37lzCiWuFY2adxQ3caDpYYGuI>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
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: Wed, 30 Oct 2019 11:12:07 -0000

On Oct 30, 2019, at 5:02 AM, Eliot Lear <lear@cisco.com> wrote:
> A fair argument, if it can be made, and I am not convinced it has been fully expressed, is the idea that there is no context by which one can separate fast restart and initial authentication.  This is Alan’s concern.  I’m not saying it’s without merit, but what I cannot yet see is whether it is an implementation or a protocol matter.

  I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the same as resumption handshakes.

  It's not clear to me how this issue was addressed when using TLS 1.3 with HTTPS.  But I do believe it's an issue there, too.

  As an additional note, I believe it's also important that draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS document.  The only unknown there is FAST and TEAP.  I'm happy to remove them from the document.

  But at this point it's not even a WG document.  There's not even consensus that the document necessary, which surprises me rather a lot.  Because password-based EAP methods are *much* more wide-spread than EAP-TLS.

  If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, it will not only look bad, it will *be* bad.  And the industry press will (rightfully) lambast the standards process.

  Alan DeKok.