| Hanno Becker | 67e49a6 | 2021-05-14 20:02:42 +0100 | [diff] [blame^] | 1 | Relaxed semantics for PSK configuration |
| 2 | ----------------------------------------------------------------- |
| 3 | |
| 4 | This affects users which call the PSK configuration APIs |
| 5 | `mbedtlsl_ssl_conf_psk()` and `mbedtls_ssl_conf_psk_opaque()` |
| 6 | multiple times on the same SSL configuration. |
| 7 | |
| 8 | In Mbed TLS 2.x, users would observe later calls overwriting |
| 9 | the effect of earlier calls, with the prevailing PSK being |
| 10 | the one that has been configured last. |
| 11 | |
| 12 | To achieve equivalent functionality when migrating to Mbed TLS 3.0, |
| 13 | users calling `mbedtls_ssl_conf_[opaque_]psk()` multiple times should |
| 14 | remove all but the last call, so that only one call to _either_ |
| 15 | `mbedtls_ssl_conf_psk()` _or_ `mbedtls_ssl_conf_psk_opaque()` |
| 16 | remains. |
| 17 | |
| 18 | However, if the _intent_ of the multiple calls to |
| 19 | `mbedtls_ssl_conf_[opaque_]psk()` was to offer multiple PSKs, then |
| 20 | users should _keep_ all calls and only check for the expected |
| 21 | non-fatal failure code `MBEDTLS_ERR_SSL_FEATURE_UNAVAILABLE` |
| 22 | indicating that no more PSKs could be buffered by the |
| 23 | implementation. |