I support adopting #443. For the server side, I have a weak preference for #457 (2) over #313 (3) because it makes it easier to implement a complete solution. I have not yet assessed how hard it is to implement ... perhaps it would be best if we all tried it out in our respective stacks and report back on the complexity?
Chris P. On Tue, Jun 22, 2021 at 3:56 PM Martin Thomson <m...@lowentropy.net> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
