Re: [TLS] ECH: Reuse HPKE context across HRR

[Stephen Farrell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>