TLS 1.3 server: Implement and test behaviour one when receiving an "early_data" extension

[ronald-cron-arm]

SPEC:
A server which receives an "early_data" extension MUST behave in one
of three ways:

• 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.
• ...

The purpose of this issue is to implement and test the behavior described just above.
The "configured max_early_data_size" should be 0 but in the case of early data associated to a valid PSK (valid from the handshake point of view) established through a NewSessionTicket where it is then equal to the max_early_data_size associated to the PSK.

Testing:
An MbedTLS client sends as part of a session resumption less early data than the maximum authorized by the associated ticket to an MbedTLS server but the server does not eventually accept early data (because the PSK ciphersuite is not available on the server for example). The PSK based handshake succeeds but not the early data transfer.

Depends on: #6341

[yuhaoth]

There are some cases in my mind.

• When MBEDTLS_SSL_EARLY_DATA disabled, we should ignore early app data.
• max_early_data_size == 0, that means disable. we should ignore early app data also.
  Above two points are finished in TLS 1.3: EarlyData: SRV: Implement mbedtls_ssl_read_early_data #6541 .

An MbedTLS client sends as part of a session resumption less early data than the maximum authorized by the associated ticket to an MbedTLS server but the server does not eventually accept early data (because the PSK ciphersuite is not available on the server for example). The PSK based handshake succeeds but not the early data transfer.

I think that means ext PSK 1-RTT fall back ? If yes, it is in #6541 also.

[mpg]

I have a question that may be stupid.

An MbedTLS client sends as part of a session resumption less early data than the maximum authorized by the associated ticket to an MbedTLS server but the server does not eventually accept early data (because the PSK ciphersuite is not available on the server for example).

When is this likely to happen in practice? The server issued the ticket, so it should support the ciphersuite in it. Is this about a case where the server was restarted with a new configuration but in a way that didn't invalidate the ticket? So the ticket is acceptable as such (in particular, the server still have the keys to decrypt it) but not for 0-RTT?

I mean, I see this in the RFC:

In addition, it MUST verify that the
following values are the same as those associated with the
selected PSK:
[...]
These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question.

so clearly if the RFC mentions it there's a reason, but scenarios where a server will accept a given ticket/PSK for 1-RTT but not for 0-RTT seem pretty rare to me.

[ronald-cron-arm]

When is this likely to happen in practice? The server issued the ticket, so it should support the ciphersuite in it. Is this about a case where the server was restarted with a new configuration but in a way that didn't invalidate the ticket? So the ticket is acceptable as such (in particular, the server still have the keys to decrypt it) but not for 0-RTT?

Yes I also think it is unlikely to happen but for 1-RTT resumption the spec does not ask for the resumption ciphersuite to be the same as the original one, only their hashes need to match. Thus the spec consider this as a possible scenario but does not allow that for early data.