Merge branch 'development' into mbedtls_private_with_python

Conflicts:
        include/mbedtls/ssl.h

Conflict fixed by using the code from development branch and
manually re-applying the MBEDTLS_PRIVATE wrapping.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,35 @@
+---
+name: Bug report
+about: To report a bug, please fill this form.
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+### Summary
+
+
+
+### System information
+
+Mbed TLS version (number or commit id): 
+Operating system and version: 
+Configuration (if not default, please attach `config.h`): 
+Compiler and options (if you used a pre-built binary, please indicate how you obtained it): 
+Additional environment information: 
+
+### Expected behavior
+
+
+
+### Actual behavior
+
+
+
+### Steps to reproduce
+
+
+
+### Additional information
+

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+    - name: Mbed TLS security team
+      url: mailto:mbed-tls-security@lists.trustedfirmware.org
+      about: Report a security vulnerability.
+    - name: Mbed TLS mailing list
+      url: https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
+      about: Mbed TLS community support and general discussion.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,17 @@
+---
+name: Enhancement request
+about: To request an enhancement, please fill this form.
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+### Suggested enhancement
+
+
+
+### Justification
+
+Mbed TLS needs this because 
+

BRANCHES.md

@@ -16,9 +16,10 @@ At any point in time, we have a number of maintained branches consisting of:
   these only get bug fixes and security fixes.
 
 We use [Semantic Versioning](https://semver.org/). In particular, we maintain
-API compatibility in the `master` branch between major version changes. We
-also maintain ABI compatibility within LTS branches; see the next section for
-details.
+API compatibility in the `master` branch across minor version changes (e.g.
+the API of 3.(x+1) is backward compatible with 3.x). We only break API
+compatibility on major version changes (e.g. from 3.x to 4.0). We also maintain
+ABI compatibility within LTS branches; see the next section for details.
 
 ## Backwards Compatibility
 
@@ -28,11 +29,28 @@ undocumented features, then you should be able to re-compile it without
 modification with any later release x.y'.z' with the same major version
 number, and your code will still build, be secure, and work.
 
-There are rare exceptions: code that was relying on something that became
-insecure in the meantime (for example, crypto that was found to be weak) may
-need to be changed. In case security comes in conflict with backwards
-compatibility, we will put security first, but always attempt to provide a
-compatibility option.
+Note that new releases of Mbed TLS may extend the API. Here are some
+examples of changes that are common in minor releases of Mbed TLS, and are
+not considered API compatibility breaks:
+
+* Adding or reordering fields in a structure or union.
+* Removing a field from a structure, unless the field is documented as public.
+* Adding items to an enum.
+* Returning an error code that was not previously documented for a function
+  when a new error condition arises.
+* Changing which error code is returned in a case where multiple error
+  conditions apply.
+* Changing the behavior of a function from failing to succeeding, when the
+  change is a reasonable extension of the current behavior, i.e. the
+  addition of a new feature.
+
+There are rare exceptions where we break API compatibility: code that was
+relying on something that became insecure in the meantime (for example,
+crypto that was found to be weak) may need to be changed. In case security
+comes in conflict with backwards compatibility, we will put security first,
+but always attempt to provide a compatibility option.
+
+## Long-time support branches
 
 For the LTS branches, additionally we try very hard to also maintain ABI
 compatibility (same definition as API except with re-linking instead of

CMakeLists.txt

@@ -16,7 +16,9 @@
 #   mbedtls, mbedx509, mbedcrypto and apidoc targets.
 #
 
-cmake_minimum_required(VERSION 2.8.12)
+# We specify a minimum requirement of 3.10.2, but for now use 3.5.1 here
+# until our infrastructure catches up.
+cmake_minimum_required(VERSION 3.5.1)
 
 # https://cmake.org/cmake/help/latest/policy/CMP0011.html
 # Setting this policy is required in CMake >= 3.18.0, otherwise a warning is generated. The OLD

ChangeLog.d/fix-ssl-cf-hmac-alt.txt

@@ -0,0 +1,5 @@
+Bugfix
+   * Fix a regression introduced in 2.24.0 which broke (D)TLS CBC ciphersuites
+     (when the encrypt-then-MAC extension is not in use) with some ALT
+     implementations of the underlying hash (SHA-1, SHA-256, SHA-384), causing
+     the affected side to wrongly reject valid messages. Fixes #4118.

ChangeLog.d/issue4286.txt

@@ -1,11 +1,10 @@
 Removals
-   * Remove the TLS 1.0, TLS 1.1 and DTLS 1.0 support by removing the following
-     library constants: MBEDTLS_SSL_PROTO_TLS1,
-     MBEDTLS_SSL_PROTO_TLS1_1, MBEDTLS_SSL_CBC_RECORD_SPLITTING,
-     MBEDTLS_SSL_CBC_RECORD_SPLITTING_ENABLED,
-     MBEDTLS_SSL_CBC_RECORD_SPLITTING_DISABLED,
-     MBEDTLS_SSL_FALLBACK_SCSV, MBEDTLS_SSL_FALLBACK_SCSV_VALUE,
-     MBEDTLS_SSL_IS_FALLBACK, MBEDTLS_SSL_IS_NOT_FALLBACK, and functions:
+   * Remove support for TLS 1.0, TLS 1.1 and DTLS 1.0, as well as support for
+     CBC record splitting, fallback SCSV, and the ability to configure
+     ciphersuites per version, which are no longer relevant. This removes the
+     configuration options MBEDTLS_SSL_PROTO_TLS1,
+     MBEDTLS_SSL_PROTO_TLS1_1, MBEDTLS_SSL_CBC_RECORD_SPLITTING and
+     MBEDTLS_SSL_FALLBACK_SCSV as well as the functions
      mbedtls_ssl_conf_cbc_record_splitting(),
-     mbedtls_ssl_get_key_exchange_md_ssl_tls(), mbedtls_ssl_conf_fallback().
-     Fixes #4286.
+     mbedtls_ssl_get_key_exchange_md_ssl_tls(), mbedtls_ssl_conf_fallback(),
+     and mbedtls_ssl_conf_ciphersuites_for_version(). Fixes #4286.

ChangeLog.d/issue4313.txt

@@ -0,0 +1,4 @@
+Removals
+   * Remove the following macros: MBEDTLS_CHECK_PARAMS,
+     MBEDTLS_CHECK_PARAMS_ASSERT, MBEDTLS_PARAM_FAILED,
+     MBEDTLS_PARAM_FAILED_ALT. Fixes #4313.

ChangeLog.d/max-record-payload-api.txt

@@ -0,0 +1,9 @@
+API changes
+   * Remove the SSL APIs mbedtls_ssl_get_input_max_frag_len() and
+     mbedtls_ssl_get_output_max_frag_len(), and add a new API
+     mbedtls_ssl_get_max_in_record_payload(), complementing the existing
+     mbedtls_ssl_get_max_out_record_payload().
+     Uses of mbedtls_ssl_get_input_max_frag_len() and
+     mbedtls_ssl_get_input_max_frag_len() should be replaced by
+     mbedtls_ssl_get_max_in_record_payload() and
+     mbedtls_ssl_get_max_out_record_payload(), respectively.

ChangeLog.d/rsa-padding.txt

@@ -0,0 +1,5 @@
+API changes
+   * mbedtls_rsa_init() now always selects the PKCS#1v1.5 encoding for an RSA
+     key. To use an RSA key with PSS or OAEP, call mbedtls_rsa_set_padding()
+     after initializing the context. mbedtls_rsa_set_padding() now returns an
+     error if its parameters are invalid.

ChangeLog.d/tool-versions.txt

@@ -0,0 +1,4 @@
+Requirement changes
+   * Refresh the minimum supported versions of tools to build the
+     library. CMake versions older than 3.10.2 and Python older
+     than 3.6 are no longer supported.

README.md

@@ -26,7 +26,7 @@ Documentation for the Mbed TLS interfaces in the default library configuration i
 
 To generate a local copy of the library documentation in HTML format, tailored to your compile-time configuration:
 
-1. Make sure that [Doxygen](http://www.doxygen.nl/) is installed. We use version 1.8.11 but slightly older or more recent versions should work.
+1. Make sure that [Doxygen](http://www.doxygen.nl/) is installed.
 1. Run `make apidoc`.
 1. Browse `apidoc/index.html` or `apidoc/modules.html`.
 
@@ -39,7 +39,7 @@ There are currently three active build systems used within Mbed TLS releases:
 
 -   GNU Make
 -   CMake
--   Microsoft Visual Studio (Microsoft Visual Studio 2013 or later)
+-   Microsoft Visual Studio
 
 The main systems used for development are CMake and GNU Make. Those systems are always complete and up-to-date. The others should reflect all changes present in the CMake and Make build system, although features may not be ported there automatically.
 
@@ -49,10 +49,13 @@ The Make and CMake build systems create three libraries: libmbedcrypto, libmbedx
 
 You need the following tools to build the library with the provided makefiles:
 
-* GNU Make or a build tool that CMake supports.
-* A C99 toolchain (compiler, linker, archiver). We actively test with GCC 5.4, Clang 3.8, IAR8 and Visual Studio 2013. More recent versions should work. Slightly older versions may work.
-* Python 3 to generate the test code, and to generate sample programs in the development branch.
+* GNU Make 3.82 or a build tool that CMake supports.
+* A C99 toolchain (compiler, linker, archiver). We actively test with GCC 5.4, Clang 3.8, IAR 8 and Visual Studio 2013. More recent versions should work. Slightly older versions may work.
+* Python 3.6 to generate the test code, and to generate sample programs in the development branch.
 * Perl to run the tests, and to generate some source files in the development branch.
+* CMake 3.10.2 or later (if using CMake).
+* Microsoft Visual Studio 2013 or later (if using Visual Studio).
+* Doxygen 1.8.11 or later (if building the documentation; slightly older versions should work).
 
 ### Generated source files in the development branch
 

docs/3.0-migration-guide.d/max-record-payload-api.md

@@ -0,0 +1,11 @@
+Remove MaximumFragmentLength (MFL) query API
+-----------------------------------------------------------------
+
+This affects users which use the MFL query APIs
+`mbedtls_ssl_get_{input,output}_max_frag_len()` to
+infer upper bounds on the plaintext size of incoming and
+outgoing record.
+
+Users should switch to `mbedtls_ssl_get_max_{in,out}_record_payload()`
+instead, which also provides such upper bounds but takes more factors
+than just the MFL configuration into account.

docs/3.0-migration-guide.d/remove_deprecated_functions_and_constants.md

@@ -50,7 +50,9 @@ The function `mbedtls_ssl_conf_dh_param()` was removed. Please use
 `mbedtls_ssl_conf_dh_param_bin()` or `mbedtls_ssl_conf_dh_param_ctx()` instead.
 
 The function `mbedtls_ssl_get_max_frag_len()` was removed. Please use
-`mbedtls_ssl_get_output_max_frag_len()` instead.
+`mbedtls_ssl_get_max_out_record_payload()` and
+`mbedtls_ssl_get_max_in_record_payload()`
+instead.
 
 Deprecated hex-encoded primes were removed from DHM
 ---------------------------------------------------

docs/3.0-migration-guide.d/remove_mbedtls_check_params_option.md

@@ -0,0 +1,33 @@
+Remove MBEDTLS_CHECK_PARAMS option
+----------------------------------
+
+This change does not affect users who use the default configuration; it only
+affects users who enabled that option.
+
+The option `MBEDTLS_CHECK_PARAMS` (disabled by default) enabled certain kinds
+of “parameter validation”. It covered two kinds of validations:
+
+- In some functions that require a valid pointer, “parameter validation” checks
+that the pointer is non-null. With the feature disabled, a null pointer is not
+treated differently from any other invalid pointer, and typically leads to a
+runtime crash. 90% of the uses of the feature are of this kind.
+- In some functions that take an enum-like argument, “parameter validation”
+checks that the value is a valid one. With the feature disabled, an invalid
+value causes a silent default to one of the valid values.
+
+The default reaction to a failed check was to call a function
+`mbedtls_param_failed()` which the application had to provide. If this function
+returned, its caller returned an error `MBEDTLS_ERR_xxx_BAD_INPUT_DATA`.
+
+This feature was only used in some classic (non-PSA) cryptography modules. It was
+not used in X.509, TLS or in PSA crypto, and it was not implemented in all
+classic crypto modules.
+
+This feature has been removed. The library no longer checks for NULL pointers;
+checks for enum-like arguments will be kept or re-introduced on a case-by-case
+basis, but their presence will no longer be dependent on a compile-time option.
+
+Validation of enum-like values is somewhat useful, but not extremely important,
+because the parameters concerned are usually constants in applications.
+
+For more information see issue #4313.

docs/3.0-migration-guide.d/remove_support_for_tls_1.0_1.1_and_dtls_1.0.md

@@ -3,9 +3,25 @@ Remove suport for TLS 1.0, 1.1 and DTLS 1.0
 
 This change affects users of the TLS 1.0, 1.1 and DTLS 1.0 protocols.
 
-The versions of (D)TLS that are being removed are not as secure as the latest
-versions. Keeping them in the library creates opportunities for misconfiguration
+These versions have been deprecated by RFC 8996.
+Keeping them in the library creates opportunities for misconfiguration
 and possibly downgrade attacks. More generally, more code means a larger attack
 surface, even if the code is supposedly not used.
 
 The migration path is to adopt the latest versions of the protocol.
+
+As a consequence of removing TLS 1.0, support for CBC record splitting was
+also removed, as it was a work-around for a weakness in this particular
+version. There is no migration path since the feature is no longer relevant.
+
+As a consequence of currently supporting only one version of (D)TLS (and in the
+future 1.3 which will have a different version negociation mechanism), support
+for fallback SCSV (RFC 7507) was also removed. There is no migration path as
+it's no longer useful with TLS 1.2 and later.
+
+As a consequence of currently supporting only one version of (D)TLS (and in the
+future 1.3 which will have a different concept of ciphersuites), support for
+configuring ciphersuites separately for each version via
+`mbedtls_ssl_conf_ciphersuites_for_version()` was removed. Use
+`mbedtls_ssl_conf_ciphersuites()` to configure ciphersuites to use with (D)TLS
+1.2; in the future a different API will be added for (D)TLS 1.3.

docs/3.0-migration-guide.d/rsa-padding.md

@@ -0,0 +1,29 @@
+Remove the padding parameters from mbedtls_rsa_init()
+-----------------------------------------------------
+
+This affects all users who use the RSA encryption, decryption, sign and
+verify APIs.
+
+The function mbedtls_rsa_init() no longer supports selecting the PKCS#1 v2.1
+encoding and its hash. It just selects the PKCS#1 v1.5 encoding by default. If
+you were using the PKCS#1 v2.1 encoding you now need, subsequently to the call
+to mbedtls_rsa_init(), to call mbedtls_rsa_set_padding() to set it.
+
+To choose the padding type when initializing a context, instead of
+```C
+    mbedtls_rsa_init(ctx, padding, hash_id);
+```
+, use
+```C
+    mbedtls_rsa_init(ctx);
+    mbedtls_rsa_set_padding(ctx, padding, hash_id);
+```
+
+To use PKCS#1 v1.5 padding, instead of
+```C
+    mbedtls_rsa_init(ctx, MBEDTLS_RSA_PKCS_V15, <ignored>);
+```
+, just use
+```C
+    mbedtls_rsa_init(ctx);
+```

include/mbedtls/check_config.h

@@ -826,6 +826,10 @@
 #error "MBEDTLS_SSL_PROTO_TLS1_1 (TLS v1.1 support) was removed in Mbed TLS 3.0. See https://github.com/ARMmbed/mbedtls/issues/4286"
 #endif
 
+#if defined(MBEDTLS_CHECK_PARAMS) //no-check-names
+#error "MBEDTLS_CHECK_PARAMS was removed in Mbed TLS 3.0. See https://github.com/ARMmbed/mbedtls/issues/4313"
+#endif
+
 #if defined(MBEDTLS_SSL_CID_PADDING_GRANULARITY) //no-check-names
 #error "MBEDTLS_SSL_CID_PADDING_GRANULARITY was removed in Mbed TLS 3.0. See https://github.com/ARMmbed/mbedtls/issues/4335"
 #endif