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