Allow the logging of Session Ticket contents and stored transport params/SETTINGS

[rmarx]

Currently, we can log which params/settings were restored upon attempting 0-RTT, but not which ones were actually stored at the end of a connection (though we might assume it were the correct ones, using the values from parameters_set).

For a server which encodes this information in for example the SessionTicket, we also cannot log which values are in the ticket when sending it, nor when receiving it, nor if early data was denied because of a mismatch therein.

[marten-seemann]

(though we might assume it were the correct ones, using the values from parameters_set)

The client might also save the RTT (and RTT variance maybe?), which would not be a QUIC transport parameter.

For a server which encodes this information in for example the SessionTicket, we also cannot log which values are in the ticket when sending it

I think all servers would encode this in the SessionTicket, but maybe we should be flexible enough to allow for other options?

The way we could do this is by introducing a parameters_saved and a parameters_restored event, which allows to encode both QUIC transport parameters and other values. We might also add a dest / src field, so we can specify where those values were saved (in the session ticket / to disk / etc.).

[marten-seemann]

Taking a long hard look at the documents, I suggest the following:

• split the TransportParametersSet event. There should be one event (keeping the TransportParametersSet name) that only logs the QUIC transport parameters, and another TLS event
• the TLS event will only capture the parts that are relevant for QUIC, e.g. cipher suite (since this determines the header protection algorithm used), the QUIC parts of the session ticket, 0-RTT etc.

[rmarx]

I'm not sure I understand how exactly that would aid solve this particular issue, unless you mean that the new TLS event would use a dest/src field as mentioned in your comment above to indicate TLSParametersSaved vs TLSParametersRestored.

I do see the appeal of having a separate TLS event. I assume it would still be under the transport category?

Can you make a (quick) mockup of what the TLSParametersSet would look like?