On Tue, Jun 22, 2021 at 6:12 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
