Re: [TLS] ECH Padding

[David Benjamin <[e-mail]>]

On Tue, Jun 22, 2021 at 6:12 PM Stephen Farrell <[e-mail]>
wrote:

> On 22/06/2021 22:57, Christopher Patton wrote:
> > Just to be clear, (1), (2) and (3) are not alternatives to the same
> > problem. (1) solves client-side padding, whereas (2) and (3) are
> > alternatives for solving server-side padding.
>
> Apologies. (Though I put part of the blame on excessive
> githubbery leading to a lack of clarity and ambiguity, as
> is my habit:-)
>
> I can live with (1) and (2) but only see any need to change
> because of the QUIC argument(s) - absent those we can work
> around things and get ECH out the door IMO.
>
> (3) is a mistake - a new handshake message shouldn't be
> adopted until after that's been tested and shown not to
> be problematic and I bet it would be problematic as well
> as lots more work
>

Could you clarify what sorts of problems you'd like to test for?

In my experience, beyond just correctly handling extensibility, the main
problem to watch for with handshake messages is optionality. That is, when
it is not defined what the next message is, your state machine needs to
branch on the received message type. (Although we've certainly done that
before, e.g. CertificateRequest.) The formulation in (3) avoids this
because the message's presence is fully determined by whether ECH was
negotiated. Gating it on some negotiation is also how you handle
extensibility. When we do that, my experience is that the implementation is
reasonable.

What we gain from that is computing padding in the right order. Unlike (3),
(2) computes the padding *before* the data being padded. It also has no way
to pad the client certificate. How tricky that is will vary based on the
padding strategy you wish to use, and padding strategies are where we have
a lot of unknowns in ECH. That seems risky to me. Needing to predict
lengths is also a source of complexity, and indeed part of the aim of (1)
was to remove a case of this.

David