0-RTT is a bit ambiguous in -01

[rmarx]

using transport.parameters_set there are two parameters to signal 0-RTT:

• resumption_allowed
• early_data_enabled

As pointed out by @jlaine, these are a bit ambiguous, as 0-RTT can either be used for the current connection or enabled for a future connection.

Solution 1:

• Rename parameters to resumption_accepted and early_data_accepted
• Add new events: session_ticket_sent/received (with early_data_enabled?:boolean member)

Solution 2:

• Rename parameters to resumption_accepted and early_data_accepted
• Add new parameters: resumption_offered and early_data_offered

[marten-seemann]

I'm not sure I agree that there's an ambiguity here, as TLS 1.3 clearly defines how the early_data extension is used. However, we currently can't log when 0-RTT is accepted / rejected (although you could infer that by observing what values TLS sends).
Maybe we should have separate events that indicate if resumption (with or without 0-RTT) was offered (on the client side), and on the server side, if it was accepted or rejected (for rejections, the reason might be interesting to log).

[marten-seemann]

Revisiting this issue. I still believe that splitting up the event is the right thing to do: parameters_set should only be used for QUIC transport parameters. We should probably have a field to indicate where these parameters came from (i.e. newly received vs. restored).

This means that we'll need to define new events for TLS session resumption / 0-RTT. As I suggested 3 years ago, this could be achieved with a resumption_offered and a resumption_accepted / resumption_rejected event.