Is the outer compression really worthwhile?

[sftcd]

(I'd suggest we resolve this issue after or with #378) Having implemented it, I don't think the compression is worthwhile and would be better omitted from the first RFC version of ECH. My reasons:

• Needless complexity
• it doesn't save enough to be worth it until there are some PQ KEMs (which is not today)
• It adds a huge burden in testing if we want to be confident that no combination is problematic
• There is no sensible way for a client to decide what to compress in general
• The set of compressed or not things may be a new fingerprint
• For OpenSSL, which supports custom extensions, it could be dangerous if there are extension handlers that interact
• There isn't really a sensible api that a library could offer to generic client applications to control this in a useful and simple manner

So my suggestion: drop it entirely for now and consider again what to do once we have some PQ KEM that's too big and when we have some real experience with ECH.

[sayrer]

There is no sensible way for a client to decide what to compress in general

In Rustls, I've found that there are some extensions that depend only on the general configuration. The API has an "extra_exts" field for things actually supplied by the caller.

https://github.com/ctz/rustls/blob/32a143fe7ff69c9f42ca2d42ec7b122e9667541c/rustls/src/client/hs.rs#L250

[davidben]

it doesn't save enough to be worth it until there are some PQ KEMs (which is not today)

That's not entirely true. We have had code in BoringSSL for an experimental PQ KEM for some time. I would be very supportive of ideas to simplify it, but dropping it altogether would be a non-starter for us. https://www.imperialviolet.org/2018/04/11/pqconftls.html https://www.imperialviolet.org/2018/12/12/cecpq2.html

There is no sensible way for a client to decide what to compress in general

I listed a couple likely strategies here: https://mailarchive.ietf.org/arch/msg/tls/dJemdTEuQxMMfxtqoU93NFd8W08/

For OpenSSL, which supports custom extensions, it could be dangerous if there are extension handlers that interact

I think any custom extensions APIs will need to ponder what to do ECH no matter what. Even without compression, you fundamentally need to decide what you put in the outer vs. inner ClientHello on the client.

• Is the ClientHello extension dependent on sensitive data? Put it in just the inner ClientHello.
• Is the ClientHello extension is public and you want to your ECH/non-ECH wire images to match here? Put it in both.
• Is it sensitive but you still want an outer value? The API will need to somehow construct both values and help the application process the server response correctly.
• Is the application assuming that all handshakes are offered this extension? You'll need to put something in both, one way or another, since the server may handshake either ClientHello.

None of these decisions are related to compression. They're fundamental to the whole outer vs. inner ClientHello design of ECH.

Once you've made that decision, whether to compress follows naturally.

• If you only put it in the inner ClientHello, this is moot.
• If you put it in both and they were publicly equal, may as well compress it.
• If you put it in both and they were not publicly equal, don't compress it.

As an aside, I don't think such custom extensions APIs are a good idea. There's no guarantee that future TLS versions won't change how extensions are used, which means they're very hard to make backwards-compatible. ECH changes extension-handling on the client, and TLS 1.3 changed it dramatically across the board.

[chris-wood]

So my suggestion: drop it entirely for now and consider again what to do once we have some PQ KEM that's too big and when we have some real experience with ECH.

I agree that it's not trivial, but we seem to have found a general design that works reasonably well. So putting aside the complexity (of implementation and testing) point temporarily, the other reasons listed seem to fall into one of three categories: YAGNI, library integration challenges (choosing what to compress, how to expose it, and how it interacts with custom extension handlers), and increased fingerprinting.

1. YAGNI: David's comments and links to PQ KEMs coming down the pipe seem to suggest this isn't a case of YAGNI.
2. Library integration: This seems mostly an issue for the library in question, and less so a problem that applies to all implementations. For example, not all TLS stacks have custom extension support anymore. (IIRC, BoringSSL had it at one point, but it was long ago removed. @davidben can confirm.) On the API point, too, it's not clear to me that exposing this as a general purpose API is something that stacks should do. Implementations can probably make reasonable decisions about what to compress and what not to compress, as David points out, without consulting the application.
3. Increased fingerprinting: This is a good point, and something we specifically have in the TLS WG charter to as a goal to mitigate.

Given the above, would a reasonable (and simpler?) alternative be to only compress the key share extension?

[cjpatton]

Key share de-duplication will be essential, operationally. It also seems likely that the future will bring other extensions we will want to de-duplicate. In my view, the "ech_outer_extensions" mechanism needs to have as much generality as it currently supports. I'd be opening to re-designing it, if someone has a suggestion for a simpler design. However, the current mechanism has been through a few design cycles (e.g., https://github.com/tlswg/draft-ietf-tls-esni/issues/262), and it seems to work pretty well.

It's also important to note that the added complexity is optional. In my experience, the client bears most of the implementation complexity, since it must decide if/how to compress extensions. The server bits are fully specified and fairly straightforward to implement properly.

[chris-wood]

Indeed, and for the record, I'm happy to keep what we have now absent some other simplifying proposal. It works and is sufficiently general for future use cases. I merely offer an alternative for consideration if we want to remove generality.

[chris-wood]

Per the interim, closing this for now. If someone comes up with something simpler, please share it!