(1) aka #443 is the way to go here I think. (Such an aptly numbered PR has to be accepted I'd say:-) I'm only convinced of that because of QUIC, but that seems like enough or a rationale.
I'm against (3) - it'd break too much and cost too much. WRT (2) I'd prefer to drop that extensibility rather than try use it because it's there. Cheers, S. On 22/06/2021 22:27, Christopher Patton wrote:
Hi all,
One of the last design questions for Encrypted ClientHello (ECH) is to
decide how to pad encrypted handshake messages so that their length does
not leak privacy-sensitive handshake-parameters. The current approach is to
insert padding into the record layer as needed. However, the consensus
reached in [1] is that computing record-layer padding based on the contents
of handshake messages entails implementation complexity that is untenable,
particularly for QUIC and DTLS. The alternative that most folks are happy
with is to insert padding into the handshake messages themselves, as this
prevents details of the handshake logic from bleeding into the record layer
code.
There are a few PRs for adding handshake-level padding that we could use
feedback on.
(1) https://github.com/tlswg/draft-ietf-tls-esni/pull/443 Adds padding
to EncodedClientHelloInner, the message that is encrypted and stuck into
the ECH extension of the ClientHelloOuter. This prevents leakage of
sensitive parameters in ClientHelloInner.
(2) https://github.com/tlswg/draft-ietf-tls-esni/pull/313 Defines a new
extension, which the client sends in ClientHelloInner in order to solicit a
response in the backend server's EncryptedExtensions message. The server''s
response contains padding it can use to prevent leakage of sensitive
parameters in its first flight of handshake messages.
(3) https://github.com/tlswg/draft-ietf-tls-esni/pull/457 (alternative
to (2)) Defines a new handshake message, Padding, which the client and
backend server always send just before Finished in case of ECH acceptance.
One advantage of this approach over (2) is that the length of the padding
can be evaluated after the Certificate/CertificateVerify messages have been
chosen, making it possible to account for sensitive parameters in these
messages without needing to buffer the whole flight of messages. The
downside is that it may add complexity to the state machine of TLS 1.3
implementations.
There are some open questions regarding how to compute the padding length,
but these should be orthogonal to deciding the mechanism.
Thanks on behalf of (some of) the contributors,
Chris P.
____
[1] "Handshake-level vs record-level padding."
https://github.com/tlswg/draft-ietf-tls-esni/issues/264
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
