Closed davidben closed 3 years ago
Seems reasonable to presume rejection, as if the extension weren't present at all, particularly if we end up GREASEing the extension.
Right now the server's not supposed to send it at all. Normally if the peer sends invalid things, we make it an error. But, yeah, allowing it and presuming rejection is plausible when we GREASE it. But that's not currently in the draft, and I'm not sure how coherent GREASEing it actually is. Right now, draft-11 as currently published is ambiguous, which makes implementing it hard.
I agree we need to say something here. The way I interpreted it in my implementation is: presume ECH acceptance if the ECH extension is present and its payload matches the acceptance signal; otherwise, presume rejection. I think we should try to spell this behavior in a way that make sense.
+1 to assuming rejection, since this is exactly what we do in the non HRR case. @davidben, will you be able to prep a PR for this today? We can include this clarification in -12. (Clarifying that clients should abort if the extension contents are malformed, e.g., of the wrong length, seems fine. But if the signal doesn't match, then I think we should just assume rejection, since that would admit greasing the signal.)
Sorry, was OOO yesterday and today was weekend email catchup. I might have time tomorrow?
Alright, sounds like everyone else prefers presuming rejection, so presuming rejection it is. :-) I feel weird doing that in advance of thinking about GREASE, but I guess folks want to do that too, so okay.
{{client-hrr}} says the client assumes ECH was accepted if the signal matches, but it doesn't say what to do if the signal doesn't match. Is it an error, or do you ignore it?
Related to #450, though whether we decide to do that, we need to write down something in the meantime.