[TLS] ECH: Reuse HPKE context across HRR

[Christopher Patton <[e-mail]>]

Hi list,

In case the server sends a HelloRetryRequest (HRR) the client generates a
fresh ECH extension, including generating a fresh HPKE context and
corresponding encapsulated key. The following PR changes the spec so that
the HPKE context generated for the first ECH extension is reused to compute
the second:
https://github.com/tlswg/draft-ietf-tls-esni/pull/352

This design has at least two advantages:

   1. Currently the spec requires the HPKE context to export a PSK, which
   in turn is used to generate the second HPKE context. This means that the
   client (resp. the server) has to implement both SetupS() (resp. SetupR())
   and SetupPSKS() (resp. SetupPSKR()). Advancing the HPKE sequence number
   before encrypting the second ClientHelloInner appears to serve the same
   purpose as the PSK (see {{flow-hrr-hijack}}.) The advantage of the new
   design is that the client (resp. the server) doesn't have to implement
   SetupPSKS() (resp. SetupPSKR()).
   2. Instead of two decapsulation operations --- one for the first CH and
   another for the second --- the server does just one decapsulation. Not only
   is this slightly more economical, it avoids edge cases that arise when
   decapsulation is offloaded to an RPC server. This allows us to simplify the
   server-side HRR logic considerably.

We're wondering if anyone can think of any disadvantages to this design.
Feedback on the PR is greatly appreciated!

Best,
Chris P.