[0-RTT] Use trial decryption if server rejects client 0-RTT attempt

[jesiegel1]

Description

This PR adds server support for handling trial decryption in order to make test output accessible for the early data rejected case by using ssl_server2.c. Without trial decryption logic, early data rejected tests that use ssl_server2.c will fail due to decryption errors caused by the client sending early data before receiving and parsing the server's extensions.

RFC 8446:
Ignore the extension and return a regular 1-RTT response. The
server then skips past early data by attempting to deprotect
received records using the handshake traffic key, discarding
records which fail deprotection (up to the configured
max_early_data_size). Once a record is deprotected successfully,
it is treated as the start of the client's second flight and the
server proceeds as with an ordinary 1-RTT handshake.

Status

READY

Requires Backporting

NO

Additional comments

The need for the skip_failed_decryption flag is to ensure we no longer drop records which fail deprotection once a record is deprotected successfully with the 1-RTT keys. The motivation was taken from Fizz, but I'd like to know if (1) there's a more appropriate place than mbedtls_ssl_read_record() to disable the flag, and (2) if there's other existing state we can leverage to avoid using an additional flag.

Todos

• Tests
• Documentation
• Changelog updated
• Backported

Steps to test or reproduce

• Run ssl-opt.sh -f 'early data status - rejected' and verify it passes.
• Revert the trial decryption changes and run ssl-opt.sh -f 'early data status - rejected' - verify it fails due to MBEDTLS_ERR_SSL_INVALID_MAC.

[hannestschofenig]

It would be good to indicate (in the comments) what the allowed value for skip_failed_decryption are.

[hannestschofenig]

I don't understand how the 4 cases are distinguished in the code below.

[jesiegel1]

skip_failed_decryption is set to 1 in one place if the client sends early data indication but server can't/won't support early data (1 and 2), and is set to 0 once a record is deprotected successfully (3).

Checking transform_in ensures handshake traffic key was used when attempting to deprotect (4). I added this condition as an invariant check since there should never be a case where skip_failed_decryption == 1 but we're using other keys.

I agree it's not immediately obvious, do you think the implementation could be more clear or just the comments?