Re: [TLS] ECH Padding

[Martin Thomson <[e-mail]>]

So I like #443 as I have said.  It simplifies padding for CHInner a lot.

I also like #457 (option 3).  My initial reaction was not positive, but I've come to appreciate the value of it.  I don't like that this has to be in the transcript (QUIC doesn't need it by virtue of a design that separates protection levels from content type), but as far as solutions go it is the easiest to implement.  In other words, it has the fewest awful shortcomings - a benchmark that has come to define ECH.

On Wed, Jun 23, 2021, at 07: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
>