Re: [TLS] ECH Padding

[Stephen Farrell <[e-mail]>]

(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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>