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

[Bernard Aboba]

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 

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

[Alan DeKok]

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.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Bernard Aboba]

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’d like 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’d like to suggest updating
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
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu