Hiya,
On 10/11/2020 22:27, Christopher Patton wrote:
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!
I've not gotten to that code yet but the above seems sensible. Cheers, S.
Best, Chris P. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
