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.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
