IETF Logo Mail Archive

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

Eliot Lear <lear@cisco.com> Wed, 30 October 2019 09:02 UTC

Return-Path: <lear@cisco.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 D3ADC12089D; Wed, 30 Oct 2019 02:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=10, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 hccZMwNYnwoy; Wed, 30 Oct 2019 02:02:28 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF148120880; Wed, 30 Oct 2019 02:02:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6905; q=dns/txt; s=iport; t=1572426148; x=1573635748; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=x5zjfPh9SN+5+RBDHucZ9lffELYTnMrjC+0ELmv1SEE=; b=d34gVkElEX0/tncAB7bt3FvNoarjj1didIAu54HIV4LwmyK2xhjLr+66 N9YRDWSaCPxSDvNF1dzrSmRQpaKqhsoDO3Dsk81yJKigEs5Zl0GwifW5x UXrT2XUcIoGDmm65uqEckkVC5Xc8TrQDe5oa/k0t85D++UBvq+Xl1cUXV I=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ATAACvULld/xbLJq1kGQEBAQEBAQEBAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWsCAQEBAQELAYNfASASKoQoiQOHcSWTCoYPgXsCBwEBAQkDAQEvAQGEQAKEAzYHDgIDAQMCAwEBBAEBAQIBBQRthUOFUQEBAQECASNWBQsLDgonAwICRhEGE4MiAYJXILI4dYEyhU6EeBCBNgGBUopWgX+BOAwTgkw+h1UygiwEljqXMoIugjOBE5FpG4I8i2GLQY9/lHeDFgIEBgUCFYFZBiyBWDMaCBsVZQGCQT4SEBSRTUADMI5sAQE
X-IronPort-AV: E=Sophos;i="5.68,246,1569283200"; d="asc'?scan'208,217";a="18536551"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Oct 2019 09:02:26 +0000
Received: from [10.61.229.214] ([10.61.229.214]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x9U92Otl005130 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Oct 2019 09:02:25 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <B31BF8C4-6568-49F2-BBD1-BD6AC66D393C@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C523ABCD-749D-436E-B43F-BFDDD5F6ACE0"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 30 Oct 2019 10:02:23 +0100
In-Reply-To: <CAOgPGoA0RCY+J5bDOyUiKtFy5Vk=C11yvE8O=rsJPQeS8Fzk0A@mail.gmail.com>
Cc: Michael Richardson <mcr@sandelman.ca>, "draft-ietf-emu-eap-tls13@ietf.org" <draft-ietf-emu-eap-tls13@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, EMU WG <emu@ietf.org>
To: Joseph Salowey <joe@salowey.net>
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>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.229.214, [10.61.229.214]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/_xfTwY67YoJJjJl7h6NyhlnwFL4>
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 09:02:30 -0000


> On 30 Oct 2019, at 06:22, Joseph Salowey <joe@salowey.net> wrote:
> 
> 
> 
> On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear <lear@cisco.com <mailto:lear@cisco.com>> wrote:
> 
> 
> > On 11 Oct 2019, at 16:09, Michael Richardson <mcr@sandelman.ca <mailto:mcr@sandelman.ca>> wrote:
> >
> > So, can wired just be a degenerate version of wifi, where there can be only
> > one "ESSID", and there are no beacons to consider?
> 
> 
> On the whole that has been my thought.  But it is a matter of which mechanism to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public keys++?  And again, this is the on-prem case.  For cloud, we are well along.
> 
> [Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem right to delay it for functionality that we are not sure we have a use case for.  If a use case develops then we can publish an update to EAP-TLS 1.3.  Do we have a use case for EAP-TLS-PSK that is blocked in the current situation?
> 

I would suggest that we do have a well-identified use case, although it has some issues, and that is IoT onboarding for on-prem equipment, as Owen described.  I do not know if we will end up executing on that use case, but it is a use case.  On the whole, the argument has to go the other way: why should we cripple a particular TLS method without strong justification?  The more we specialize the longer it takes to deliver new services, and the harder they are to support.

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.

Eliot

> 
> 
> Eliot

v2.23.0 | Report a Bug | By Email