Define HelloRetryRequestInner/Outer messages #407
Conversation
Co-authored-by: ekr <ekr@rtfm.com>
|
|
||
| The payload of the "encrypted_client_hello" extension is constructed as follows. | ||
| The client-facing server begins by computing `hrr_inner_key` and | ||
| `hrr_inner_nonce` as described in {{client-hrr-accepted-ech}}. The extension |
There was a problem hiding this comment.
(This is a note not just about this PR but the document in general.) I'm finding it confusing for all the client behavior discussed in one section and the server behavior discussed in another. I'm bouncing back and forth from one to the other to get the actual ordering of the series of events. Would it not be less confusing to put things in that order than to describe all the client behavior and then all the server behavior?
There was a problem hiding this comment.
Hmmm, that's an interesting idea. I wonder which is easier from the perspective of someone who is implementing this for the first time. My assumption has been that it's better to separate client behavior and server behavior into two section so that the implementer needs only to refer to one section when implementing the client (resp. server) bits. But given how complex ECH is, perhaps a chronological description is better. I think this sort of editorial re-work is worth filing an issue for discussion.
| HelloRetryRequestInner to construct ClientHelloInner per the rules of | ||
| {{RFC8446}}. It then encodes the second ClientHelloInner as in | ||
| {{encoding-inner}}, except that it does not incorporate any extensions from the | ||
| ClientHelloOuter (i.e., the "ech_outer_extensions" extension is not used). It |
There was a problem hiding this comment.
(i.e., the "ech_outer_extensions" extension is not used)
Why is this?
There was a problem hiding this comment.
The idea here is that there's no need to incorporate outer extensions because since the inner handshake was taken. However, it occurs to me that this assumption might not be correct, depending on how the "TODO" above is resolved. I wonder, are there any extensions that MUST appear in CHOuter (according to the HRR rules prescribed by 8446), but which one would want to incorporate here? "supported_versions" is the only extension I know of that MUST appear in the CHOuter, but there's no reason to incorporate it.
The design is based on @davidben's sketch.
Closes #374.
Closes #373.
Closes #358.
Closes #333.