[TLS] Handshake-level vs record-level padding in TLS ECH

[David Benjamin <[e-mail]>]

Hi all,

In discussing ECH (draft-ietf-tls-esni) with some QUIC folks, we identified
some places where the extension would not easily apply to QUIC unmodified.
One of them is ECH’s integration of handshake information (anonymity set of
certificates, etc.) with TLS record-level padding. Since QUIC both replaces
the record layer and runs over UDP, that means this padding crosses
TLS/QUIC public APIs and must be integrated into QUIC retransmission logic.

I wrote some notes up in the GitHub issue here:
https://github.com/tlswg/draft-ietf-tls-esni/issues/264

I wanted to find out both WGs’ thoughts on how to handle padding here, as
it seems we have a mismatch between the interfaces TLS assumes and QUIC
provides. The HTTP/3 draft briefly mentions a similar issue and has its own
stream-level padding story alongside the transport-level one.
https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-padding-and-traffic-analysi

We could match that in ECH, which would remove the need for TLS and QUIC to
coordinate here but adds another padding mechanism. Or we could leave
things as-is, which means ECH will require folks to add a parameter to
their TLS/QUIC APIs and then implement more complex retransmission logic
before usefully deploying ECH. (Something that should probably be reflected
in the QUIC spec.)

David