Hi Watson, Could you elaborate on your proposal? In particular: How does the client transmit its supported versions? What does "compatible" mean? What does "the server selects" mean? What does "the server proceeds" mean?
Thanks, David On Wed, Mar 10, 2021 at 1:55 PM Watson Ladd <[email protected]> wrote: > Dear WG, > > I'd like to proffer the world's simplest version negotiation scheme, > based on comments heard during the meeting today from a number of > people. > > The following weak assumptions are made: the client has a set of > versions. The server has a partial ordering on versions: this means > that versions are not necessarily preferred over each other (consider > experiments where we will do what the client offers first), but the > relation is transitive. Then the server selection is a function of the > client offered version and supported set. > > The client transmits its supported versions and a proffered hello > version in the first packet. The server selects. If that selection is > incompatible they try again with the new selected version transmitted > in VN. If it is compatible, the server selects and proceeds. > > The constraint on the handshake is that the supported versions and > offered version and server selection are incorporated on the handshake > in such a way that a mismatch triggers failure, and no two different > versions can derive the same keys. If we assume that e.g. SHA256 is > unbroken this is easy to get. > > This only permits a downgrade to a version the server was willing to > prefer. > > Sincerely, > Watson Ladd > >
