Subject: Re: [saag] [Emu] RFC 5216 updates, backwards compatibility and open source

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Oct 2017 18:57:09 -0700

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 <[email-masked]>
wrote:

> On Oct 26, 2017, at 8:24 PM, Bernard Aboba <[email-masked]>
> 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.
>
>