Initial grease codepoints

[chris-wood]

Closes #451

cc @davidben, @dennisjackson, @cjpatton

[sftcd]

What's the expected behaviour of an ECHConfig generator that wants to include a "mandatory" GREASE ECH extension in an HTTTPS RR? If it really ought to include >1 entry in the ECHConfigList in that case (incl. one without that mandatory GREASE ECH extension) then we should say that. (Better would be to get rid of these mandatory extensions IMO, but that's a different topic.)

[chris-wood]

I don't think there are any expected behaviors for config generators -- they can put as many greased values in the thing as they want.

[sftcd]

But then doesn't that mean that all consumers of ECHConfig values MUST know about the GREASE values and ignore those with the mandatory bit set? Don't we need to say that?

[chris-wood]

I don't think it needs to be explicit. If the client knows it's a grease value, then it will recognize the mandatory bit and "ignore" it as desired (it understands that the extension value is grease), but if it doesn't know it's a grease value then it'll drop the config.

[sftcd]

Right, if the client drops the config then things break unless the ECHConfig generator made a list where one doesn't have the "mandatory" GREASE codepoint. I think the text as-is is likely to leave a crack into which what may be different sets of implementers may fall, causing interop issues.

[chris-wood]

@sftcd feel free to suggest text if you think it's warranted. I'm OK with the text as-is.

[sftcd]

Sure, I'd add "Clients MUST know of, and ignore, all these codepoints, including those with the high-order bit set."

[sftcd]

Sorry if the above is better supplied some other way, but not sure if you do/don't want 2119 terms in IANA considerations which'd affect where the suggested sentence goes maybe.

[kazuho]

@sftcd

Sure, I'd add "Clients MUST know of, and ignore, all these codepoints, including those with the high-order bit set."

Or, we could add something like "Some extension IDs are reserved for greasing; clients MUST ignore them" to the last paragraph of Section 4.2. That's where we define how the client parses all the extensions.

[davidben]

Requiring clients know about grease values would be counterproductive and defeat the point of greasing. Indeed, we specifically want the high-order bit values to be treated as unrecognized mandatory extensions. This way config generators can ensure clients actually implement this correctly! Add a bunch of garbage ECHConfigs with unrecognized mandatory configs to make sure clients exercise skipping it.

[davidben]

That is, the current text is fine and we definitely should not use the suggested replacement. I'll add a suggestion for a sentence or two, since it sounds like the implications of "Note that the reserved values with the high-order bit set to 1 are mandatory, as defined in {{config-extensions}}" are not obvious.