Are mandatory ECH extensions deployable?

[sftcd]

We currently have a way to mark ECH extensions as mandatory via the high-bit of their codepoint.

I can't see a way in which that's deployable without being the equivalent of cutting a new codepoint for the ECH TLS extension.

Do we have any outline scenarios that indicate this mandatory ECH extension mechanism is deployable?

If not, it may be better to remove it. (I'd be for removing it:-)

[davidben]

I'm not sure what you mean by deployable. The compatibility requirement here is just that clients know to skip over mandatory extensions, just like they need to know to skip over unknown codepoints.

Mandatory extensions are very similar to cutting a new top-level version, yes. That's generally true in any protocols. The main difference is in how to coordinate changes. We could have cut extensions out of TLS entirely and simply bumped the version every time we wanted to extend it. (Extension lists were an IETF innovation. SSL 3.0 did not have them and extended by appending to the ClientHello.) Indeed in a protocol from a single vendor, that is probably a better and simpler extensibility strategy. But in the IETF's multi-vendor protocols, it can be useful for extensions to be defined, implemented, and deployed at different rates. Thus, extension lists, with their various semantics on how to handle unknown ones.

Whether extending ECH rises to this sort of thing being useful, I don't know. But I don't think the question is deployability, nor is the litmus test simply whether it's equivalent to bumping the top-level version. That litmus test would knock out every extension scheme the IETF has ever produced. :-)

[sftcd]

The compatibility requirement here is just that clients know to skip over mandatory extensions, just like they need to know to skip over unknown codepoints.

Is that the case? Doesn't a client need to skip over an entire ECHConfig if it encounters a mandatory extension that it does not support?

[davidben]

Yes, sorry, sloppy phrasing on my part. I meant skip over the whole ECHConfig.

[dennisjackson]

I have a hypothetical use case for mandatory extensions. Let's call this extension "Alternative Cover Names". It contains a list of website names as a payload. If ECH is rejected, the client should authenticate the resulting connection against the cover name or any of the website names in this extension, accepting the retry ECHConfigs if any verification succeeds. This extension needs to be mandatory, because otherwise clients which don't support the extension will only validate against the cover name and won't be able to retrieve retry configs.

I'd much rather keep the mandatory byte, it allows for a much wider range of experimentation than non-mandatory extensions.

[sftcd]

Fair enough that it's a hypothetical but won't servers who want to use that need to publish two ECHConfigs one with, and one without, your new ACN extension? So that'd mean they still need to be able to authenticate retry_configs using the public_name from the ECHConfig without ACN, reducing the hypothetical benefit a lot? I guess I'm just skeptical that this'll turn out to be a useful bit (not byte:-) in the ECH extension codepoints,

WRT experiments, I do think those'd be better done using a different TLS extension codepoint in general, though fair enough that that's not a strong argument.

[dennisjackson]

The value of (mandatory) extensions is that you can combine orthogonal ones in way that is tedious with codepoint bumps. I don't want to speculate about how the ecosystem could develop, but I'd rather keep the flexibility to allow folks to find their own use cases. It's a tiny amount of complexity in terms of implementation.

[sftcd]

It's true that if we have ECH extensions, the additional code complexity of handling the mandatory bit is tiny. (I'd prefer we just get rid of ECH extensions entirely, but seem to have lost that argument:-)

OTOH, is there any history of mandatory extensions being successful in IETF protocols? I think the experience with e.g. X.509 criticality shows that at least didn't work, but maybe there's some example somewhere that did, I dunno.

[davidben]

I think the headache with X.509 is only somewhat analogous. The ecosystem around X.509 moves much, much more slowly, and is often deployed in problematic ways. (This thing where servers have a single certificate chain for all clients is such a mess.)

And then protocol-wise, X.509 made criticality a decision you make when you encode the individual field. Sometimes an extension is critical and sometimes it isn't. ECH extensions avoid this and make it part of the codepoint. I.e., it's a decision we make when we design the field.

When we use extension points, we need to reason about what happens when one side is older and the other side is newer. A lot of protocol engineering is trying to get the right thing to happen. Things like critical/mandatory extensions, etc., are tools in our toolbox for getting that right thing to happen. If we're in a context where sometimes we want the older receiver to ignore it, and sometimes we want them to reject it, that's exactly what a mandatory bit is for.

You don't see this in TLS only because TLS is a very online protocol, so one side can just say "I know about this" and everything flows from there. ECH and X.509 are different because the relevant structures are much more static.

[sftcd]

Reasonable points, but count me unconvinced. I'll leave it there for now, and I guess if others don't chime in arguing to remove the feature, it'll be ok to close this issue.

[chris-wood]

Closing per discussion at IETF 118.