Closed cjpatton closed 3 years ago
Oh whoops, nice catch! Using 0xfe0a
definitely won't work since the format and corresponding ClientECH extension has changed. I suppose all the implementors could just agree to mentally fix this typo when reading the draft, but may as well cut draft-12. Draft numbers are cheap.
We could try to pick up some editorial changes, too, like those suggested in #454.
I'd also personally be pretty happy to have #443 in there, but also fine to skip it for what's supposed to be a small bugfix draft snapshot.
On 22/06/2021 20:43, David Benjamin wrote:
Oh whoops, nice catch! Using
0xfe0a
definitely won't work since the format and corresponding ClientECH extension has changed. I suppose all the implementors could just agree to mentally fix this typo when reading the draft, but may as well cut draft-12. Draft numbers are cheap.
+1
I've not checked recent editorial changes but they're probably fine too.
S
I'd be happy to take #443 in draft-12 as well, though I'm inclined to think this should strictly be a bugfix/editorial draft. I'd say let's wait until Chris W. gets off back from PTO and let him make the call. Unless we're in a hurry, in which case we could ping one of the other authors to merge our changes and cut a draft.
Closing as resolved.
ECHConfig is defined as
but the text below it says
The intention was to bump ECHConfig.version from 0xfe0a to 0xfe0b for draft-11, but this got missed by https://github.com/tlswg/draft-ietf-tls-esni/pull/458. (I wrote the PR, so I apologize for my part in missing this.) How do folks think we should resolve this? Do we need to cut a new draft with the ambiguity fixed?