This PR cleans up the client text, in hopes of making it more precise
and organized somewhat more chronologically. It then uses this cleanup
to clarify bits we forgot to write down in the accept/reject/HRR
machinery:
Handling the Server Response is now Determining ECH Acceptance and
only discusses the initial accept/reject decision.
The portion of Handling HelloRetryRequest discussing the
accept/reject decision is moved to Determining ECH Acceptence.
Determining ECH Acceptance is tidied up to discuss to what happens if
you see an older TLS version (it's a reject). In particular, in DTLS
1.2, the first server message might be HelloVerifyRequest and not
ServerHello or HelloRetryRequest.
Accepted/Rejected ECH are now Handshaking with
ClientHelloInner/ClientHelloOuter to fit with the other section names
(lots of VERBing). They are unindented from (1) because that section
only talks about the accept/reject decision. This gives us a place to
discuss all changes to the handshake. We describe what it actually
means to handshake with ClientHelloInner, including implications to
the transcript. And...
...the portion of Handling HelloRetryRequest that discussed
constructing the second ClientHello never applied to the ECH Reject
case anyway, only ECH Accept. Move this to (4). Also expand on it so
it's a bit more clearly defined. I've also moved HPKE setup out of
Encrypting the ClientHello, as that's only relevant to one of the two
"callers" anyway. I'm not thrilled with this notion of "partial
ClientHelloOuterAAD", but the text used in Offering ECH and
Encrypting the ClientHello sections otherwise doesn't actually match.
Before this PR, both think they are responsible for constructing
ClientHelloOuter.
With this and (1), Handling HelloRetryRequest is
now empty and removed.
We say that the ECH reject case ignores the HRR.ech extension, so ECH
GREASE says the same thing, to keep them aligned.
The Handshaking with ClientHelloOuter section could also do with an
editorial pass, but I've omitted it from this PR because it was getting
a bit large as it is.
This PR cleans up the client text, in hopes of making it more precise and organized somewhat more chronologically. It then uses this cleanup to clarify bits we forgot to write down in the accept/reject/HRR machinery:
Handling the Server Response is now Determining ECH Acceptance and only discusses the initial accept/reject decision.
The portion of Handling HelloRetryRequest discussing the accept/reject decision is moved to Determining ECH Acceptence.
Determining ECH Acceptance is tidied up to discuss to what happens if you see an older TLS version (it's a reject). In particular, in DTLS 1.2, the first server message might be HelloVerifyRequest and not ServerHello or HelloRetryRequest.
Accepted/Rejected ECH are now Handshaking with ClientHelloInner/ClientHelloOuter to fit with the other section names (lots of VERBing). They are unindented from (1) because that section only talks about the accept/reject decision. This gives us a place to discuss all changes to the handshake. We describe what it actually means to handshake with ClientHelloInner, including implications to the transcript. And...
...the portion of Handling HelloRetryRequest that discussed constructing the second ClientHello never applied to the ECH Reject case anyway, only ECH Accept. Move this to (4). Also expand on it so it's a bit more clearly defined. I've also moved HPKE setup out of Encrypting the ClientHello, as that's only relevant to one of the two "callers" anyway. I'm not thrilled with this notion of "partial ClientHelloOuterAAD", but the text used in Offering ECH and Encrypting the ClientHello sections otherwise doesn't actually match. Before this PR, both think they are responsible for constructing ClientHelloOuter.
With this and (1), Handling HelloRetryRequest is now empty and removed.
We forgot to write down the client half of https://github.com/tlswg/draft-ietf-tls-esni/pull/461. There is now a place for it in Handshaking with ClientHelloInner.
We say that the ECH reject case ignores the HRR.ech extension, so ECH GREASE says the same thing, to keep them aligned.
The Handshaking with ClientHelloOuter section could also do with an editorial pass, but I've omitted it from this PR because it was getting a bit large as it is.