From nobody Thu Oct 26 17:25:06 2017 Return-Path: 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 1AAA513F491 for ; Thu, 26 Oct 2017 17:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ag0hofEcqvgF for ; Thu, 26 Oct 2017 17:25:01 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9554A13B1A9 for ; Thu, 26 Oct 2017 17:25:01 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id n38so3728666uai.11 for ; Thu, 26 Oct 2017 17:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=56GDpaBQGkwIehj6yXLKqMqCfaE6btuYNhiIiPwNuzg=; b=olBCL7Ab7a0j+2OPAoyixW5f2qtZKHDdSFMlVk+qUlYzGKpQbDdfFFhiqb7wAeBIey LUFnV29LqDjLSA0BblHKLS1NgACKuehS0HVnpgZVvMEMM63B5KVPGSbKeJ01G0/kGV+5 /4DjiKB2w7ED1GPO+JelhlplxZ55S1bS8PsI+sI3ixpWt0VEdp7TCD2zVSpIVfCogEwn 7o1ytKCSlHFrUeH5tRPQEEUYjOmaZTmg25Hr41ohQhM78IEXZtS5Cvid3ViQlZT0FTZ0 Q4Hx700S+vo9ywAt0b6H2YEpY/oUhjzV9uN7qF1BiHGw7pdG00YEWRCrwbm+yjmSwNMH FnWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=56GDpaBQGkwIehj6yXLKqMqCfaE6btuYNhiIiPwNuzg=; b=l7xj1hB/tUU/yLuWVrSxTzBZK8ILM35hQxcqhoyYiJyejvJg3HpfZwXA+Med5UlFhD zhSsPjetufaNd7mMGDn0FdpDdHCqpbTT9x5kI8ofTpUr6I9Pb5p71/2rq6KglMrXuZZP t4uJw//XEL5zMZTCCKtBDGmY0KYbvAFdSPScXlkgsD0BMi1AfiSkTkSK30v/kov/YjIj AdblGa5f97j3Ce2coK6PNYHbiig79Z0p2a75TvckYmsqVZJN38XYPBkOamxyXfP1Yzwe AeueidfWsWBkECPISNbbrp2romCGJOE7fkxU3JFc8O36i3m+wLmXqVbJWN50477IXI01 Aqyg== X-Gm-Message-State: AMCzsaX6e34wtaJguYg5Ti2ouom+OfIZmFt1Lpt+juJWUSfML0H5wD0n 5DiNoeMWayzmbWi55DP5TOB6rv3BjaPsBq2WuO+fXICZ X-Google-Smtp-Source: ABhQp+TzMQsNgCAI0PGvOH8WMJn5RVZrE6JtfhFKaCMHNUtb0wZoIprtXDQCsI22LsiA6NvZsZbwMwP9iJCDIIV7Dzs= X-Received: by 10.176.22.77 with SMTP id l13mr1801767uae.65.1509063900395; Thu, 26 Oct 2017 17:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 17:24:39 -0700 (PDT) From: Bernard Aboba Date: Thu, 26 Oct 2017 17:24:39 -0700 Message-ID: To: emu@ietf.org Content-Type: multipart/alternative; boundary="001a1144f7b8b9fc0c055c7c5154" Archived-At: Subject: Re: [Emu] RFC 5216 updates, backwards compatibility and open source X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:25:04 -0000 --001a1144f7b8b9fc0c055c7c5154 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With implementations shipping on virtually every major platform (e.g. Android, iOS, Mac OS X, Windows, Linux ,etc.) EAP-TLS (RFC 5216) is now supported on 2+ billion devices worldwide. This includes numerous open source implementations for both the EAP client and server. In particular, EAP-TLS, due to its focus on certificate-authentication, has been deployed widely in environments requiring the highest levels of security, such as critical infrastructure, and military/national security installations. In these environments, EAP-TLS's provable security properties are considered critical, as is backward compatibility with the hardware ecosystem that has grown up around EAP-TLS, providing addons such as employee smartcard badges, or hardware-based certificate storage. Given the enormous number of deployed devices, the widespread implementation in open source, and the potential impact on national security and critical infrastructure, it is very important that updates to EAP-TLS consider backwards compatibility, retain the provable security, and avoid introduction of royalty-bearing IPR and the introduction of security vulnerabilities. To provide backwards as well as forwards compatibility, EAP-TLS was designed to to support new versions of TLS, including versions introducing new ciphersuites. So while RFC 5216 mandates support for TLS 1.0 to preserve backwards compatibility, it does not mandate the use of TLS 1.0 or any other version in a given installation. This allows organizations to manage their deployments (and required ciphersuites) as they see fit. For example, an organization wiling to take on the costs of migrating all of their devices and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated ciphersuites is fully able to do so within the framework laid out by RFC 5216. However, what RFC 5216 does NOT attempt to do is to mandate a world-wide non-backward compatible "forklift" upgrade for TLS versions of ciphersuites. Such a non-backward compatible "forklift" update would be extra-ordinarily costly, requiring the upgrading of every device implementing EAP-TLS, including devices that do not use the protocol regularly, if ever. Despite this lack of "central management" imposed by the IETF, the record of EAP-TLS forward compatibility appears to be pretty good. At this point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am aware of several implementations of EAP-TLS now testing support for TLS 1.3, without any changes to the protocol. I was therefore surprised to come across draft-mattsson-eap-tls13 which: 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS. As noted earlier, organizations requiring support for TLS 1.3 can easily impose such a requirement on their EAP-TLS devices, if the cost and security benefits justify it. However, since RFC 5216 is referenced in many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without extraordinary justification (such as discovery of a critical security flaw that cannot be patched in previous versions) would impose enormous costs. 2. Invalidates the existing security proofs of EAP-TLS by introducing new authentication modes (such as EAP PSK) that were specifically rejected by the EMU WG so to ensure that high-security installations could ensure that certificate-based authentication, and only cert-based authentication was provided by their EAP-TLS implementations. This reversal of an EMU WG decision is very unwise since it has the potential to introduce new security vulnerabilities into the systems protecting some of the world's most sensitive data. 3. Removes much of the security guidance of RFC 5216 addressing known interoperability and security issues. 4. Does not discuss the potential IPR implications of introducing a TLS 1.3 requirement into a protocol that is widely implemented in open source. -------------------------------------- Although I see that the EMU WG concluded earlier this year, I=E2=80=99d lik= e to ask those on this mail list to consider whether an update to RFC 5216 may be worth pursuing. Wireless LAN deployments commonly leverage the EAP-TLS standard. The IEEE took steps earlier this year to raise the bar for wireless security through publishing the new 802.11ac standard. RFC 5216 currently requires TLS 1.0, and the only mandatory cipher suite specified is TLS_RSA_WITH_3DES_EDE_CBC_SHA. I=E2=80=99d like to suggest upd= ating the standard in a manner that also requires mandatory support for TLS 1.2 and ECDHE_ECDSA AEAD cipher suites. Best regards, Clint Clint McKay NSA Information Assurance --001a1144f7b8b9fc0c055c7c5154 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With implementations shipping on virtually every majo= r platform (e.g. Android, iOS, Mac OS X, Windows, Linux ,etc.) EAP-TLS (RFC= 5216) is now supported on=C2=A0 2+ billion devices worldwide. This include= s numerous open source implementations for both the EAP client and server.= =C2=A0

In particular, EAP-TLS, due to its focus on= certificate-authentication, has been deployed widely in environments requi= ring the highest levels of security, such as critical infrastructure, and m= ilitary/national security installations.=C2=A0 In these environments, EAP-T= LS's provable security properties are considered critical, as is backwa= rd compatibility with the hardware ecosystem that has grown up around EAP-T= LS, providing addons such as employee smartcard badges, or hardware-based c= ertificate storage.

Given the enormous number of d= eployed devices, the widespread implementation in open source, and the pote= ntial impact on national security and critical infrastructure, it is very i= mportant that updates to EAP-TLS consider backwards compatibility, retain t= he provable security, and avoid introduction of royalty-bearing IPR and the= introduction of security vulnerabilities.=C2=A0

T= o provide backwards as well as forwards compatibility, EAP-TLS was designed= to to support new versions of TLS, including versions introducing new ciph= ersuites.=C2=A0=C2=A0
So while RFC 5216 mandates support for TLS = 1.0 to preserve backwards compatibility, it does not mandate the use of TLS= 1.0 or any other version in a given installation.=C2=A0 This allows organi= zations to manage their deployments (and required ciphersuites) as they see= fit.=C2=A0 For example, an organization wiling to take on the costs of mig= rating all of their devices and servers to TLS 1.3 and requiring the use of= TLS 1.3 mandated ciphersuites is fully able to do so within the framework = laid out by RFC 5216.=C2=A0

However, what RFC 5216= does NOT attempt to do is to mandate a world-wide non-backward compatible = "forklift" upgrade for TLS versions of ciphersuites.=C2=A0 Such a= non-backward compatible "forklift" update would be extra-ordinar= ily costly, requiring the upgrading of every device implementing EAP-TLS, i= ncluding devices that do not use the protocol regularly, if ever.

Despite this lack of "central management" imposed= by the IETF, the record of EAP-TLS forward compatibility appears to be pre= tty good. At this point support for TLS 1.1 and 1.2 in EAP-TLS has widely d= eployed and I am aware of several implementations of EAP-TLS now testing su= pport for TLS 1.3, without any changes to the protocol.

I was therefore surprised to come across draft-mattsson-eap-tls13 whi= ch:=C2=A0

1. Mandates support for TLS 1.3 in all i= mplementations of EAP-TLS.=C2=A0 As noted earlier, organizations requiring = support for TLS 1.3 can easily impose such a requirement on their EAP-TLS d= evices, if the cost and security benefits justify it.=C2=A0 However, since = RFC 5216 is referenced in many RFPs, obsoleting it merely to impose a TLS 1= .3 requirement without extraordinary justification (such as discovery of a = critical security flaw that cannot be patched in previous versions) would i= mpose enormous costs.=C2=A0=C2=A0

2. Invalidates t= he existing security proofs of EAP-TLS by introducing new authentication mo= des (such as EAP PSK) that were specifically rejected by the EMU WG so to e= nsure that high-security installations could ensure that certificate-based = authentication, and only cert-based authentication was provided by their EA= P-TLS implementations.=C2=A0=C2=A0

This reversal o= f an EMU WG decision is very unwise since it has the potential to introduce= new security vulnerabilities into the systems protecting some of the world= 's most sensitive data.=C2=A0=C2=A0

3. Removes= much of the security guidance of RFC 5216 addressing known interoperabilit= y and security issues.=C2=A0

4. Does not discuss t= he potential IPR implications of introducing a TLS 1.3 requirement into a p= rotocol that is widely implemented in open source.





--------------= ------------------------

Although I see that the EMU WG concluded earli= er this year, I=E2=80=99d like to ask those on this mail list to consider w= hether an update to RFC 5216 may be worth pursuing.


Wireless LAN deployments com= monly leverage the EAP-TLS standard. The IEEE took steps earlier this year = to raise the bar for wireless security through publishing the new 802.11ac = standard.


RFC 5216 currently requires TLS 1.0, and the only mandatory cipher sui= te specified is TLS_RSA_WITH_3DES_EDE_CBC_SHA. I=E2=80=99d like to suggest = updating the standard in a manner that also requires mandatory support for = TLS 1.2 and ECDHE_ECDSA AEAD cipher suites.

=C2=A0

Best regards,

Clint

=C2=A0

Clint McKay

NSA Information Assurance

--001a1144f7b8b9fc0c055c7c5154-- From nobody Thu Oct 26 17:57:46 2017 Return-Path: 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 EA93513B1A9 for ; Thu, 26 Oct 2017 17:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 uCWnwDCxFraL for ; Thu, 26 Oct 2017 17:57:42 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 90F4413F415 for ; Thu, 26 Oct 2017 17:57:42 -0700 (PDT) Received: from [192.168.2.9] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 7B6FD2E0; Fri, 27 Oct 2017 00:57:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 26 Oct 2017 20:57:38 -0400 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com> References: To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Emu] RFC 5216 updates, backwards compatibility and open source X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:57:45 -0000 On Oct 26, 2017, at 8:24 PM, Bernard Aboba = wrote: > To provide backwards as well as forwards compatibility, EAP-TLS was = designed to to support new versions of TLS, including versions = introducing new ciphersuites. =20 > So while RFC 5216 mandates support for TLS 1.0 to preserve backwards = compatibility, it does not mandate the use of TLS 1.0 or any other = version in a given installation. This allows organizations to manage = their deployments (and required ciphersuites) as they see fit. For = example, an organization wiling to take on the costs of migrating all of = their devices and servers to TLS 1.3 and requiring the use of TLS 1.3 = mandated ciphersuites is fully able to do so within the framework laid = out by RFC 5216. \ Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic. Not = because TLS1.2 is bad, but because in some cases, the upgrade was = *mandated* by the OS vendor. This forced upgrade caused massive = incompatibilities. Which led the OS vendors to back off on their = requirements. i.e. with billions of devices supporting EAP-TLS, there are hundreds = of millions which support only old versions of TLS. Devices which = cannot realistically be upgraded. Moving to newer versions of TLS is a decision best left to site = administrators. They should be *strongly recommended* to use the best = available crypto. But mandating it is counter-productive. Such = mandates cause administrators to stick with older server software that = is compatible with older systems. > However, what RFC 5216 does NOT attempt to do is to mandate a = world-wide non-backward compatible "forklift" upgrade for TLS versions = of ciphersuites. Such a non-backward compatible "forklift" update would = be extra-ordinarily costly, requiring the upgrading of every device = implementing EAP-TLS, including devices that do not use the protocol = regularly, if ever. >=20 > Despite this lack of "central management" imposed by the IETF, the = record of EAP-TLS forward compatibility appears to be pretty good. At = this point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed = and I am aware of several implementations of EAP-TLS now testing support = for TLS 1.3, without any changes to the protocol. That has been my experience, too. > I was therefore surprised to come across draft-mattsson-eap-tls13 = which:=20 >=20 > 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS. As = noted earlier, organizations requiring support for TLS 1.3 can easily = impose such a requirement on their EAP-TLS devices, if the cost and = security benefits justify it. However, since RFC 5216 is referenced in = many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without = extraordinary justification (such as discovery of a critical security = flaw that cannot be patched in previous versions) would impose enormous = costs. =20 >=20 > 2. Invalidates the existing security proofs of EAP-TLS by introducing = new authentication modes (such as EAP PSK) that were specifically = rejected by the EMU WG so to ensure that high-security installations = could ensure that certificate-based authentication, and only cert-based = authentication was provided by their EAP-TLS implementations. =20 >=20 > This reversal of an EMU WG decision is very unwise since it has the = potential to introduce new security vulnerabilities into the systems = protecting some of the world's most sensitive data. =20 >=20 > 3. Removes much of the security guidance of RFC 5216 addressing known = interoperability and security issues.=20 >=20 > 4. Does not discuss the potential IPR implications of introducing a = TLS 1.3 requirement into a protocol that is widely implemented in open = source. I concur. Not only because I'm an open source implementor. But also because = that software supports networks encompassing hundreds of millions of = devices. Software which is used by all network equipment vendors. It is just infeasible to mandate that all devices upgrade to TLS 1.3. For me, it's 2017. Any proposal that does not address existing = deployments is one that should be ignored, as being out of touch with = real-world use-cases. Alan DeKok. From nobody Thu Oct 26 18:46:32 2017 Return-Path: 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 A561D13F4CB for ; Thu, 26 Oct 2017 18:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tXNVD0CvrBIO for ; Thu, 26 Oct 2017 18:46:28 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8C913A41F for ; Thu, 26 Oct 2017 18:46:28 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id d12so3314052vkf.1 for ; Thu, 26 Oct 2017 18:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4rlF3T/4AFrv7BMlm7XAbzxWwZfV+74ocl6TryaA1o0=; b=hoxLhbayEgk53ZK56cj60qi3y6O9BpcaP/7B8cLIR363ZHtFXYDNnIFnFwloCFJ0pi Fz8DVqD2VnRVYV8CxcncrxOswzPAtAzqRWkFvPlLNpeuPPbbMG/CH/NqNVv/n0AeIZFD XZxQjbOlgCBs+0Yee4fF13pPNKmVfqBXO9JOCVBP/dQtzSznKbAQftTt/uHRQHJURT3o EUcicYXPZakh2P34rVqQzKb1ePzhFGAX01H2GSnTvZjeFvnpiG10o3Zudd1uGqReptRH zbWlAkIp/QwG0UQD1mlSIrAUIPdq/xSla9svy/zfZndWWI5ugWKVhPFp+CwGnMQOyK0B 097A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4rlF3T/4AFrv7BMlm7XAbzxWwZfV+74ocl6TryaA1o0=; b=qSV6t2E9jDy+pLFf33kvXaMXe6+XkoS0m1R7PCjC5HwbwVGJb0nzBTP9yYHQ6nJyvi /sOT1Mk2X39NwxyJmPtRTravfi47Wqj+tafquCx6Sp63qhfSiFH7YH12k+DoLS+lp+Wy BtceW695xjnKTfIwpFj8MBRxzez9/SJJd8wD8pXC1lkqOBt6dZd0b27fcU4KU+rLf7kv NmSEjHWKiXSel2cqTuzh5tqTxn7widDkFyvhFxdOlvKg1qv9/OvL6Uf68bKjprzcQLr3 GoTdUfS/Q78ciUpFrIs/86SiZKiXOm0T8V6K0q2uoih6ZZbMJ5wyJYSdq727xYUhJqt3 d6CQ== X-Gm-Message-State: AMCzsaU3CCX4RFD3QWjFR/X5E/E+eTKglUysfKPyYrLIufpWM7LYse+5 iSE+9jjNBmHYCesmkaMJgF3WjUj9GpjqEaNjhLg= X-Google-Smtp-Source: ABhQp+TrY76RmcoIiGbEBQNyQayH7JXUCKU2imXXnwi+jRHzFtw1CiDUpIPKeGyHQr6kFrg3ksGtjXORawgh9MY6QzA= X-Received: by 10.31.63.19 with SMTP id m19mr5162384vka.24.1509068787072; Thu, 26 Oct 2017 18:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 18:46:06 -0700 (PDT) In-Reply-To: <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com> References: <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com> From: Bernard Aboba Date: Thu, 26 Oct 2017 18:46:06 -0700 Message-ID: To: Alan DeKok Cc: emu@ietf.org Content-Type: multipart/alternative; boundary="001a114dd7d0fec584055c7d74ed" Archived-At: Subject: Re: [Emu] RFC 5216 updates, backwards compatibility and open source X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 01:46:30 -0000 --001a114dd7d0fec584055c7d74ed Content-Type: text/plain; charset="UTF-8" Alan said: " I concur. Not only because I'm an open source implementer. But also because that software supports networks encompassing hundreds of millions of devices. Software which is used by all network equipment vendors. It is just infeasible to mandate that all devices upgrade to TLS 1.3." [BA] The scale of EAP implementation is truly sobering - billions of devices. Not only does this involve software, but also hardware such as badges that may not support new ciphersuites (e.g. elliptic curves). Given that support for RFC 5216 may be required due to security policies or regulatory mandates, requiring those organizations to throw away all those badges and replace them requires serious justification, and concurrence from respected organizations known for their cryptographic and security expertise, such as NIST. Without a *serious* justification (such as an unpatchable vulnerability), attempting to impose a "forced migration" is not just practically infeasible - it is deeply irresponsible, and would expose the IETF to very well deserved ridicule. Alan also said: "For me, it's 2017. Any proposal that does not address existing deployments is one that should be ignored, as being out of touch with real-world use-cases." [BA] I fully agree. On Thu, Oct 26, 2017 at 5:57 PM, Alan DeKok wrote: > On Oct 26, 2017, at 8:24 PM, Bernard Aboba > wrote: > > To provide backwards as well as forwards compatibility, EAP-TLS was > designed to to support new versions of TLS, including versions introducing > new ciphersuites. > > So while RFC 5216 mandates support for TLS 1.0 to preserve backwards > compatibility, it does not mandate the use of TLS 1.0 or any other version > in a given installation. This allows organizations to manage their > deployments (and required ciphersuites) as they see fit. For example, an > organization wiling to take on the costs of migrating all of their devices > and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated > ciphersuites is fully able to do so within the framework laid out by RFC > 5216. \ > > Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic. Not > because TLS1.2 is bad, but because in some cases, the upgrade was > *mandated* by the OS vendor. This forced upgrade caused massive > incompatibilities. Which led the OS vendors to back off on their > requirements. > > i.e. with billions of devices supporting EAP-TLS, there are hundreds of > millions which support only old versions of TLS. Devices which cannot > realistically be upgraded. > > Moving to newer versions of TLS is a decision best left to site > administrators. They should be *strongly recommended* to use the best > available crypto. But mandating it is counter-productive. Such mandates > cause administrators to stick with older server software that is compatible > with older systems. > > > However, what RFC 5216 does NOT attempt to do is to mandate a world-wide > non-backward compatible "forklift" upgrade for TLS versions of > ciphersuites. Such a non-backward compatible "forklift" update would be > extra-ordinarily costly, requiring the upgrading of every device > implementing EAP-TLS, including devices that do not use the protocol > regularly, if ever. > > > > Despite this lack of "central management" imposed by the IETF, the > record of EAP-TLS forward compatibility appears to be pretty good. At this > point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am > aware of several implementations of EAP-TLS now testing support for TLS > 1.3, without any changes to the protocol. > > That has been my experience, too. > > > I was therefore surprised to come across draft-mattsson-eap-tls13 which: > > > > 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS. As > noted earlier, organizations requiring support for TLS 1.3 can easily > impose such a requirement on their EAP-TLS devices, if the cost and > security benefits justify it. However, since RFC 5216 is referenced in > many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without > extraordinary justification (such as discovery of a critical security flaw > that cannot be patched in previous versions) would impose enormous costs. > > > > 2. Invalidates the existing security proofs of EAP-TLS by introducing > new authentication modes (such as EAP PSK) that were specifically rejected > by the EMU WG so to ensure that high-security installations could ensure > that certificate-based authentication, and only cert-based authentication > was provided by their EAP-TLS implementations. > > > > This reversal of an EMU WG decision is very unwise since it has the > potential to introduce new security vulnerabilities into the systems > protecting some of the world's most sensitive data. > > > > 3. Removes much of the security guidance of RFC 5216 addressing known > interoperability and security issues. > > > > 4. Does not discuss the potential IPR implications of introducing a TLS > 1.3 requirement into a protocol that is widely implemented in open source. > > I concur. > > Not only because I'm an open source implementor. But also because that > software supports networks encompassing hundreds of millions of devices. > Software which is used by all network equipment vendors. > > It is just infeasible to mandate that all devices upgrade to TLS 1.3. > > For me, it's 2017. Any proposal that does not address existing > deployments is one that should be ignored, as being out of touch with > real-world use-cases. > > Alan DeKok. > > --001a114dd7d0fec584055c7d74ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"=C2=A0 I concur.

=C2=A0 Not only because I'm an open = source implementer.=C2=A0 But also because that software supports networks = encompassing hundreds of millions of devices.=C2=A0 Software which is used = by all network equipment vendors.=C2=A0=C2=A0It is just infeasible to mandate that all devices upgrade to TLS = 1.3."

[BA] The scale of EAP implementation is truly sobering - billions of devi= ces. Not only does this involve software, but also hardware such as badges = that may not support new ciphersuites (e.g. elliptic curves).=C2=A0 Given t= hat support for RFC 5216 may be required due to security policies or regula= tory mandates, requiring those organizations to throw away all those badges= and replace them requires serious justification, and concurrence from resp= ected organizations known for their cryptographic and security expertise, s= uch as NIST.

Without a *serious* justification (su= ch as an unpatchable vulnerability), attempting to impose a "forced mi= gration" is not just practically infeasible - it is deeply irresponsib= le, and would expose the IETF to very well deserved ridicule.=C2=A0

Alan also said:=C2=A0

"For me, it's 2017.=C2= =A0 Any proposal that does not address existing deployments is one that sho= uld be ignored, as being out of touch with real-world use-cases.&quo= t;

[BA] I fully agree.

On Thu, Oct 26, 2017 at 5:5= 7 PM, Alan DeKok <aland@deployingradius.com> wrote:<= br>
On Oct 26, 2017, at 8:24= PM, Bernard Aboba <bernard.a= boba@gmail.com> wrote:
> To provide backwards as well as forwards compatibility, EAP-TLS was de= signed to to support new versions of TLS, including versions introducing ne= w ciphersuites.
> So while RFC 5216 mandates support for TLS 1.0 to preserve back= wards compatibility, it does not mandate the use of TLS 1.0 or any other ve= rsion in a given installation.=C2=A0 This allows organizations to manage th= eir deployments (and required ciphersuites) as they see fit.=C2=A0 For exam= ple, an organization wiling to take on the costs of migrating all of their = devices and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated ci= phersuites is fully able to do so within the framework laid out by RFC 5216= . \

=C2=A0 Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic.=C2= =A0 Not because TLS1.2 is bad, but because in some cases, the upgrade was *= mandated* by the OS vendor.=C2=A0 This forced upgrade caused massive incomp= atibilities.=C2=A0 Which led the OS vendors to back off on their requiremen= ts.

=C2=A0 i.e. with billions of devices supporting EAP-TLS, there are hundreds= of millions which support only old versions of TLS.=C2=A0 Devices which ca= nnot realistically be upgraded.

=C2=A0 Moving to newer versions of TLS is a decision best left to site admi= nistrators.=C2=A0 They should be *strongly recommended* to use the best ava= ilable crypto.=C2=A0 But mandating it is counter-productive.=C2=A0 Such man= dates cause administrators to stick with older server software that is comp= atible with older systems.

> However, what RFC 5216 does NOT attempt to do is to mandate a world-wi= de non-backward compatible "forklift" upgrade for TLS versions of= ciphersuites.=C2=A0 Such a non-backward compatible "forklift" up= date would be extra-ordinarily costly, requiring the upgrading of every dev= ice implementing EAP-TLS, including devices that do not use the protocol re= gularly, if ever.
>
> Despite this lack of "central management" imposed by the IET= F, the record of EAP-TLS forward compatibility appears to be pretty good. A= t this point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and= I am aware of several implementations of EAP-TLS now testing support for T= LS 1.3, without any changes to the protocol.

=C2=A0 That has been my experience, too.

> I was therefore surprised to come across draft-mattsson-eap-tls13 whic= h:
>
> 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS.=C2= =A0 As noted earlier, organizations requiring support for TLS 1.3 can easil= y impose such a requirement on their EAP-TLS devices, if the cost and secur= ity benefits justify it.=C2=A0 However, since RFC 5216 is referenced in man= y RFPs, obsoleting it merely to impose a TLS 1.3 requirement without extrao= rdinary justification (such as discovery of a critical security flaw that c= annot be patched in previous versions) would impose enormous costs.
>
> 2. Invalidates the existing security proofs of EAP-TLS by introducing = new authentication modes (such as EAP PSK) that were specifically rejected = by the EMU WG so to ensure that high-security installations could ensure th= at certificate-based authentication, and only cert-based authentication was= provided by their EAP-TLS implementations.
>
> This reversal of an EMU WG decision is very unwise since it has the po= tential to introduce new security vulnerabilities into the systems protecti= ng some of the world's most sensitive data.
>
> 3. Removes much of the security guidance of RFC 5216 addressing known = interoperability and security issues.
>
> 4. Does not discuss the potential IPR implications of introducing a TL= S 1.3 requirement into a protocol that is widely implemented in open source= .

=C2=A0 I concur.

=C2=A0 Not only because I'm an open source implementor.=C2=A0 But also = because that software supports networks encompassing hundreds of millions o= f devices.=C2=A0 Software which is used by all network equipment vendors.
=C2=A0 It is just infeasible to mandate that all devices upgrade to TLS 1.3= .

=C2=A0 For me, it's 2017.=C2=A0 Any proposal that does not address exis= ting deployments is one that should be ignored, as being out of touch with = real-world use-cases.

=C2=A0 Alan DeKok.


--001a114dd7d0fec584055c7d74ed-- From nobody Thu Oct 26 18:57:36 2017 Return-Path: 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 94251139F18; Thu, 26 Oct 2017 18:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ByL5ShYTT6wz; Thu, 26 Oct 2017 18:57:31 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F8A13968C; Thu, 26 Oct 2017 18:57:31 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id n22so3849184uaj.13; Thu, 26 Oct 2017 18:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JnFaB6yrqfYxxvJU15GPaY+TSRtHt2dAzJ3U3CY6bnA=; b=fZP4DOlAZWSxGB1/++REsMRQskX7HHzfxs7MXAELz8y/M3nSxK/S7Eg4zFgK+WZPb+ mahvgi3xHr18yf3/2MszlYjjbRa5U4jCgIKkZ7D6uMSyryaJBQesGTUC9bsH8TrBW3bz VQdoqP0Psn1n4eaxM9+gwujwrF+fqHAJBgIvy3680+vO3E6rDbGxDkCWUnnSbOsRf+YX D1FvUt7oVVOxX1ylgXYSixI82fmaYMszsZluxOKQh8LnIg+TGZrF7jBgkWd3+e/cBA7v VKo3NnlqQ63OLWCBC5TjC0FtvHFYTpGmRJtDLkXVfMTAVcF1jgDtYqTZng70C5Dk89uW Rb/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JnFaB6yrqfYxxvJU15GPaY+TSRtHt2dAzJ3U3CY6bnA=; b=qhDOFMH7oDSPL4dxOb+45p+XSv9ybBhz5fkLY+KVQrriRHjS9zZtucltywxfIVNfuY 3E/uU0HqOBBmtsvuUmRr+repTHb80M0cDgflcpMrpuT1MI/KlaWXKDq4Fq7dcmFrtvhN pjfFw7mvRzfyT/gPn8a/4/oVjUUcCTzshyah5Y6IP/VXNLAqDQdb2PR/o/65eA7AuQ6P mQypot+7eVXs8CTXoQcHaDkBjKl70yBSSWEXnvshczQTcZw1c54ZNZs4C88kywRdfXTW k78lAjqay1ZAcOqx1Rl6VWx/+ktsyTRiAtCdqia9Wwt7epLfIBHNGKeScgGHLyBITkrO iROA== X-Gm-Message-State: AMCzsaWHtFUel5RNhnWi2/IyB07lyto5imOJ+4s5ftftZm91VNQ9lkYZ OIJ55MstKn4fs602GkXMYM9B5uYkJDq0cUQZYQE= X-Google-Smtp-Source: ABhQp+S9pJDQDmc7QIgNwd5bjMduvtK6JFD8RF9fwzJ5fgb59sSrU0DTB9shD9OKP3JuysxSih7mtYSbTpii41Lqf4A= X-Received: by 10.176.81.68 with SMTP id f4mr5203676uaa.52.1509069450106; Thu, 26 Oct 2017 18:57:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 18:57:09 -0700 (PDT) In-Reply-To: <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com> References: <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com> From: Bernard Aboba Date: Thu, 26 Oct 2017 18:57:09 -0700 Message-ID: To: Alan DeKok , saag Cc: emu@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19131883dc85055c7d9cfb" Archived-At: Subject: Re: [Emu] RFC 5216 updates, backwards compatibility and open source X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 01:57:33 -0000 --94eb2c19131883dc85055c7d9cfb Content-Type: text/plain; charset="UTF-8" Alan said: "Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic. Not because TLS1.2 is bad, but because in some cases, the upgrade was *mandated* by the OS vendor. This forced upgrade caused massive incompatibilities. Which led the OS vendors to back off on their requirements. i.e. with billions of devices supporting EAP-TLS, there are hundreds of millions which support only old versions of TLS. Devices which cannot realistically be upgraded." [BA] Yes, in practice, the upgrade from EAP-TLS with TLS 1.0 to EAP-TLS with TLS 1.1 or 1.2 had to be very carefully orchestrated, both because of protocol and ciphersuite issues. "Moving to newer versions of TLS is a decision best left to site administrators. They should be *strongly recommended* to use the best available crypto. But mandating it is counter-productive. Such mandates cause administrators to stick with older server software that is compatible with older systems." [BA] Fully agree. In practice those decisions often need to take into account guidance from regulators or organizations that seek to summarize industry "best practices". Organizations (such as NIST) think through the migration issues very carefully in order to balance the costs and benefits, and minimize disruptions. On Thu, Oct 26, 2017 at 5:57 PM, Alan DeKok wrote: > On Oct 26, 2017, at 8:24 PM, Bernard Aboba > wrote: > > To provide backwards as well as forwards compatibility, EAP-TLS was > designed to to support new versions of TLS, including versions introducing > new ciphersuites. > > So while RFC 5216 mandates support for TLS 1.0 to preserve backwards > compatibility, it does not mandate the use of TLS 1.0 or any other version > in a given installation. This allows organizations to manage their > deployments (and required ciphersuites) as they see fit. For example, an > organization wiling to take on the costs of migrating all of their devices > and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated > ciphersuites is fully able to do so within the framework laid out by RFC > 5216. \ > > Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic. Not > because TLS1.2 is bad, but because in some cases, the upgrade was > *mandated* by the OS vendor. This forced upgrade caused massive > incompatibilities. Which led the OS vendors to back off on their > requirements. > > i.e. with billions of devices supporting EAP-TLS, there are hundreds of > millions which support only old versions of TLS. Devices which cannot > realistically be upgraded. > > Moving to newer versions of TLS is a decision best left to site > administrators. They should be *strongly recommended* to use the best > available crypto. But mandating it is counter-productive. Such mandates > cause administrators to stick with older server software that is compatible > with older systems. > > > However, what RFC 5216 does NOT attempt to do is to mandate a world-wide > non-backward compatible "forklift" upgrade for TLS versions of > ciphersuites. Such a non-backward compatible "forklift" update would be > extra-ordinarily costly, requiring the upgrading of every device > implementing EAP-TLS, including devices that do not use the protocol > regularly, if ever. > > > > Despite this lack of "central management" imposed by the IETF, the > record of EAP-TLS forward compatibility appears to be pretty good. At this > point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am > aware of several implementations of EAP-TLS now testing support for TLS > 1.3, without any changes to the protocol. > > That has been my experience, too. > > > I was therefore surprised to come across draft-mattsson-eap-tls13 which: > > > > 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS. As > noted earlier, organizations requiring support for TLS 1.3 can easily > impose such a requirement on their EAP-TLS devices, if the cost and > security benefits justify it. However, since RFC 5216 is referenced in > many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without > extraordinary justification (such as discovery of a critical security flaw > that cannot be patched in previous versions) would impose enormous costs. > > > > 2. Invalidates the existing security proofs of EAP-TLS by introducing > new authentication modes (such as EAP PSK) that were specifically rejected > by the EMU WG so to ensure that high-security installations could ensure > that certificate-based authentication, and only cert-based authentication > was provided by their EAP-TLS implementations. > > > > This reversal of an EMU WG decision is very unwise since it has the > potential to introduce new security vulnerabilities into the systems > protecting some of the world's most sensitive data. > > > > 3. Removes much of the security guidance of RFC 5216 addressing known > interoperability and security issues. > > > > 4. Does not discuss the potential IPR implications of introducing a TLS > 1.3 requirement into a protocol that is widely implemented in open source. > > I concur. > > Not only because I'm an open source implementor. But also because that > software supports networks encompassing hundreds of millions of devices. > Software which is used by all network equipment vendors. > > It is just infeasible to mandate that all devices upgrade to TLS 1.3. > > For me, it's 2017. Any proposal that does not address existing > deployments is one that should be ignored, as being out of touch with > real-world use-cases. > > Alan DeKok. > > --94eb2c19131883dc85055c7d9cfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan said:

"Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic= .=C2=A0 Not because TLS1.2 is bad, but because in some cases, the upgrade w= as *mandated* by the OS vendor.=C2=A0 This forced upgrade caused massive in= compatibilities.=C2=A0 Which led the OS vendors to back off on their requir= ements.

=C2=A0 i.e. with billions of devices supporting EAP-TLS, there are= hundreds of millions which support only old versions of TLS.=C2=A0 Devices= which cannot realistically be upgraded."

[B= A] Yes, in practice, the upgrade from EAP-TLS with TLS 1.0 to EAP-TLS with = TLS 1.1 or 1.2 had to be very carefully orchestrated, both because of proto= col and ciphersuite issues.=C2=A0

"Moving to newer versions of TLS is a decision b= est left to site administrators.=C2=A0 They should be *strongly recommended= * to use the best available crypto.=C2=A0 But mandating it is counter-produ= ctive.=C2=A0 Such mandates cause administrators to stick with older server = software that is compatible with older systems."

=
[BA] Fully agree. In practice those decisions often need to take= into account guidance from regulators or organizations that seek to summar= ize industry "best practices".=C2=A0 Organizations (such as NIST)= think through the migration issues very carefully in order to balance the = costs and benefits, and minimize disruptions.

On Thu, Oct 26, 2017 at 5:5= 7 PM, Alan DeKok <aland@deployingradius.com> wrote:<= br>
On Oct 26, 2017, at 8:24= PM, Bernard Aboba <bernard.a= boba@gmail.com> wrote:
> To provide backwards as well as forwards compatibility, EAP-TLS was de= signed to to support new versions of TLS, including versions introducing ne= w ciphersuites.
> So while RFC 5216 mandates support for TLS 1.0 to preserve back= wards compatibility, it does not mandate the use of TLS 1.0 or any other ve= rsion in a given installation.=C2=A0 This allows organizations to manage th= eir deployments (and required ciphersuites) as they see fit.=C2=A0 For exam= ple, an organization wiling to take on the costs of migrating all of their = devices and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated ci= phersuites is fully able to do so within the framework laid out by RFC 5216= . \

=C2=A0 Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic.=C2= =A0 Not because TLS1.2 is bad, but because in some cases, the upgrade was *= mandated* by the OS vendor.=C2=A0 This forced upgrade caused massive incomp= atibilities.=C2=A0 Which led the OS vendors to back off on their requiremen= ts.

=C2=A0 i.e. with billions of devices supporting EAP-TLS, there are hundreds= of millions which support only old versions of TLS.=C2=A0 Devices which ca= nnot realistically be upgraded.

=C2=A0 Moving to newer versions of TLS is a decision best left to site admi= nistrators.=C2=A0 They should be *strongly recommended* to use the best ava= ilable crypto.=C2=A0 But mandating it is counter-productive.=C2=A0 Such man= dates cause administrators to stick with older server software that is comp= atible with older systems.

> However, what RFC 5216 does NOT attempt to do is to mandate a world-wi= de non-backward compatible "forklift" upgrade for TLS versions of= ciphersuites.=C2=A0 Such a non-backward compatible "forklift" up= date would be extra-ordinarily costly, requiring the upgrading of every dev= ice implementing EAP-TLS, including devices that do not use the protocol re= gularly, if ever.
>
> Despite this lack of "central management" imposed by the IET= F, the record of EAP-TLS forward compatibility appears to be pretty good. A= t this point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and= I am aware of several implementations of EAP-TLS now testing support for T= LS 1.3, without any changes to the protocol.

=C2=A0 That has been my experience, too.

> I was therefore surprised to come across draft-mattsson-eap-tls13 whic= h:
>
> 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS.=C2= =A0 As noted earlier, organizations requiring support for TLS 1.3 can easil= y impose such a requirement on their EAP-TLS devices, if the cost and secur= ity benefits justify it.=C2=A0 However, since RFC 5216 is referenced in man= y RFPs, obsoleting it merely to impose a TLS 1.3 requirement without extrao= rdinary justification (such as discovery of a critical security flaw that c= annot be patched in previous versions) would impose enormous costs.
>
> 2. Invalidates the existing security proofs of EAP-TLS by introducing = new authentication modes (such as EAP PSK) that were specifically rejected = by the EMU WG so to ensure that high-security installations could ensure th= at certificate-based authentication, and only cert-based authentication was= provided by their EAP-TLS implementations.
>
> This reversal of an EMU WG decision is very unwise since it has the po= tential to introduce new security vulnerabilities into the systems protecti= ng some of the world's most sensitive data.
>
> 3. Removes much of the security guidance of RFC 5216 addressing known = interoperability and security issues.
>
> 4. Does not discuss the potential IPR implications of introducing a TL= S 1.3 requirement into a protocol that is widely implemented in open source= .

=C2=A0 I concur.

=C2=A0 Not only because I'm an open source implementor.=C2=A0 But also = because that software supports networks encompassing hundreds of millions o= f devices.=C2=A0 Software which is used by all network equipment vendors.
=C2=A0 It is just infeasible to mandate that all devices upgrade to TLS 1.3= .

=C2=A0 For me, it's 2017.=C2=A0 Any proposal that does not address exis= ting deployments is one that should be ignored, as being out of touch with = real-world use-cases.

=C2=A0 Alan DeKok.


--94eb2c19131883dc85055c7d9cfb--