[Python-checkins] peps: PEP 466: Network security enhancement exception

[nick.coghlan]

http://hg.python.org/peps/rev/78a067318208
changeset:   5420:78a067318208
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Mar 23 06:53:40 2014 +1000
summary:
  PEP 466: Network security enhancement exception

files:
  pep-0466.txt |  283 +++++++++++++++++++++++++++++++++++++++
  1 files changed, 283 insertions(+), 0 deletions(-)


diff --git a/pep-0466.txt b/pep-0466.txt
new file mode 100644
--- /dev/null
+++ b/pep-0466.txt
@@ -0,0 +1,283 @@
+PEP: 466
+Title: Network Security Enhancement Exception for All Branches
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Coghlan <ncoghlan at gmail.com>,
+Status: Draft
+Type: Informational
+Content-Type: text/x-rst
+Created: 23-Mar-2014
+Post-History: 23-Mar-2014
+
+
+Abstract
+========
+
+Most CPython tracker issues are classified as errors in behaviour or
+proposed enhancements. Most patches to fix behavioural errors are
+applied to all active maintenance branches.  Enhancement patches are
+restricted to the default branch that becomes the next Python version.
+
+This PEP relaxes the latter restriction allowing enhancements to be applied
+to maintenance branches for standard library components that have
+implications for the overall security of the internet. In particular, the
+exception will apply to:
+
+* the ``ssl`` module
+* the ``hashlib`` module
+* the ``hmac`` module
+* the ``sha`` module (Python 2 only)
+* the components of other networking modules that make use of these modules
+* the components of the ``random`` and ``os`` modules that are relevant to
+  cryptographic applications
+* the version of OpenSSL bundled with the binary installers
+
+Changes to these modules will still need to undergo normal backwards
+compatibility assessments, but new features will be permitted where
+appropriate, making it easier to implement secure networked software in
+Python, even for software that needs to remain compatible with older feature
+releases of Python.
+
+
+Exemption Policy
+================
+
+Under this policy, the following network security related modules are
+granted a blanket exemption to the restriction against adding new features
+in maintenance releases:
+
+* the ``ssl`` module
+* the ``hashlib`` module
+* the ``hmac`` module
+* the ``sha`` module (Python 2 only)
+
+This exemption applies to *all* proposals to backport backwards compatible
+features in these modules to active maintenance branches. This choice is
+made deliberately to ensure that the "feature or fix?" argument isn't simply
+replaced by a "security related or not?" argument. These particular modules
+are inherently security related, and all enhancements to them improve
+Python's capabilities as a platform for development of secure networked
+software.
+
+As part of this policy, permission is also granted to upgrade to newer
+feature releases of OpenSSL when preparing the binary installers
+for new maintenance releases of CPython.
+
+In addition to the above blanket exemption, a conditional exemption is
+granted for these modules that may include some network security related
+features:
+
+* the ``os`` module (primarily ``os.urandom``)
+* the ``random`` module
+* networking related modules that depend on one or more of the network
+  security related modules listed above
+
+This more limited exemption for these modules requires that the *specific*
+enhancement being proposed for backporting needs to be justified as being
+network security related. If the enhancement under discussion is designed
+to take advantage of a new feature in one of the network security related
+modules, then that will be taken as implying that the enhancement is
+security related.
+
+
+Backwards Compatibility Considerations
+======================================
+
+This PEP does *not* grant any general exemptions to the usual backwards
+compatibility policy for maintenance releases. Instead, it is designed
+to make it easier to provide more "secure by default" behaviour in future
+feature releases, while still limiting the risk of breaking currently
+working software when upgrading to a new maintenance release.
+
+In *all* cases where this policy is applied to backport enhancements to
+maintenance releases, it MUST be possible to write cross-version compatible
+code that operates by "feature detection" (for example, checking for
+particular attributes in the module), without needing to explicitly check
+the Python version.
+
+It is then up to library and framework code to provide an appropriate error
+message or fallback behaviour if a desired feature is found to be missing.
+
+Affected APIs SHOULD be designed to allow library and application code to
+perform the following actions after detecting the presence of a relevant
+network security related feature:
+
+* explicitly opt in to more secure settings (to allow the use of enhanced
+  security features in older versions of Python)
+* explicitly opt in to less secure settings (to allow the use of newer Python
+  versions in lower security environments)
+* determine the default setting for the feature (this MAY require explicit
+  Python version checks to determine the Python feature release, but MUST
+  NOT depend on the specific maintenance release)
+
+
+Documentation Requirements
+==========================
+
+All modules that take advantage of this policy to backport network
+security related enhancements to earlier Python versions MUST include
+a "Security Considerations" section in their documentation.
+
+In addition to any other module specific contents, this section MUST
+enumerate key security enhancements and fixes (with CVE identifiers where
+applicable), and the
+
+
+Evolution of this Policy
+========================
+
+The key requirement for a module to be considered for inclusion in this
+policy (whether under a blanket or conditional exemption) is that it must
+have security implications *beyond* the specific application that is written
+in Python and the system that application is running on. Thus the focus on
+network security protocols and related cryptographic infrastructure - Python
+is a popular choice for the development of web services and clients, and
+thus the capabilities of widely used Python versions have implications for
+the security design of other services that may be using newer versions of
+Python or other development languages.
+
+The intent behind this requirement is to minimise any impact that the
+introduction of this policy may have on the stability and compatibility of
+maintenance releases. It would be thoroughly counterproductive if end
+users became as cautious about updating to new Python maintenance releases
+as they are about updating to new feature releases.
+
+
+Motivation and Rationale
+========================
+
+This PEP can be seen as a more targeted version of the "faster standard
+library release cycle" proposals discussed in PEP 407 and PEP 413,
+focusing specifically on those areas which have implications beyond the
+Python community.
+
+The creation of this PEP was prompted primarily by the aging SSL support in
+the Python 2 series. As of March 2014, the Python 2.7 SSL module is
+approaching four years of age, and the SSL support in the still popular
+Python 2.6 release had its feature set locked six years ago.
+
+These are simply too old to provide a foundation that can be recommended
+in good conscience for secure networking software that operates over the
+public internet, especially in an era where it is becoming quite clearly
+evident that advanced persistent security threats are even more widespread
+and more indiscriminate in their targeting than had previously been
+understood.
+
+While the use of the system OpenSSL installation addresses many of these
+concerns on Linux platforms, it doesn't address all of them, and in the
+case of the binary installers for Windows and Mac OS X that are published
+on python.org, the version of OpenSSL used is entirely within the control
+of the Python core development team.
+
+With increased popularity comes increased responsibility, and this policy
+is about recognising the fact that Python's popularity and adoption has now
+reached a level where some of our design and policy decisions have
+significant implications beyond the Python development community.
+
+As one example, the Python 2 ``ssl`` module does not support the Server
+Name Identification standard. While it is possible to obtain SNI support
+by using the third party ``requests`` client library, actually doing so
+currently requires using not only ``requests`` and its embedded dependencies,
+but also half a dozen or more additional libraries. The lack of support
+in the Python 2 series thus serves as an impediment to making effective
+use of SNI on servers, as Python 2 clients will frequently fail to handle
+it correctly.
+
+Another more critical example is the lack of SSL hostname matching in the
+Python 2 standard library - it is currently necessary to rely on a third
+party library, such as ``requests`` or ``backports.ssl_match_hostname`` to
+obtain that functionality in Python 2.
+
+The Python 2 series also remains more vulnerable to remote timing attacks
+on security sensitive comparisons than the Python 3 series, as it lacks a
+standard library equivalent to the timing attack resistant
+``hmac.compare_digest()`` function. While appropriate secure comparison
+functions can be implemented in third party extensions, may users don't
+even consider the problem and use ordinary equality comparisons instead
+- while a standard library solution doesn't automatically fix that problem,
+it *does* make the barrier to resolution much lower once the problem is
+pointed out.
+
+My position on the ongoing transition from Python 2 to Python 3 has long
+been that Python 2 remains a supported platform for the core development
+team, and that commercial support will remain available well after upstream
+maintenance ends. However, in the absence of this network security
+enhancement policy, that position is difficult to justify when it comes to
+software that operates over the public internet. Just as many developers
+consider it too difficult to develop truly secure modern networked software
+in C/C++ (largely due to the challenges associated with manual
+memory management), I consider it too difficult to develop truly secure
+modern networked software using the Python 2 series without introducing this
+network security enhancement policy, as doing so would mean reimplementing
+substantial portions of the standard library as third party modules to gain
+access to the newer underlying network security protocols and mechanisms,
+and then injecting those into the module namespace to override their
+standard library counterparts.
+
+Requiring that latent defects in an application's Unicode correctness be
+addressed in order to migrate to Python 3 is not a reasonable alternative
+recommendation, especially given the likely existence of legacy code that
+lacks the kind of automated regression test suite needed to help support
+a migration from Python 2 to Python 3. The key point of this PEP is that
+those situations affect more people than just the developers and users of
+the affected application: their existence becomes something that developers
+of secure networked services need to take into account as part of their
+security design. By making it more feasible to enhance the security of the
+Python 2 series, we can help contribute to the evolution of a more secure
+internet for all concerned.
+
+For the Python 2 series, this proposal will most obviously impact the
+remaining maintenance releases of Python 2.7. However, commercial
+redistributors that continue to offer full support for Python 2.6, and will
+also do so for Python 2.7 after upstream maintenance ends, may choose
+to take this policy into account when deciding what changes to backport to
+their own maintenance updates. Providing commercial redistributors such
+as ActiveState, Attachmate, Canonical, Continuum Analytics, Enthought, and
+Red Hat that option is one of the benefits offered by requiring feature
+detection based forward compatibility for the modules covered by this policy.
+
+
+Open Questions
+==============
+
+* What are the risks associated with allowing OpenSSL to be updated to
+  new feature versions in the Windows and Mac OS X binary installers for
+  maintenance releases?
+
+* Are there any other security relevant modules that should be covered
+  by either a blanket or conditional exemption?
+
+* Should we enumerate a specific list of "other networking modules" rather
+  than leaving it implicit?
+
+
+Acknowledgement
+===============
+
+Thanks to Christian Heimes for his recent efforts on greatly improving
+Python's SSL support in the Python 3 series, and a variety of members of
+the Python community for helping me to better understand the implications
+of the default settings we provide in our SSL modules, and the impact that
+tolerating the use of SSL infrastructure that was defined in 2010
+(Python 2.7) or even 2008 (Python 2.6) potentially has for the security
+of the web as a whole.
+
+Christian and Donald Stufft also provided valuable feedback on a preliminary
+draft of this proposal.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+

+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End:

-- 
Repository URL: http://hg.python.org/peps