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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
