Re: Analysis of version negotiation

[Martin Thomson <[e-mail]>]

Hey folks,

I spent a few minutes and updated this document.  Part of that involved removing another field (the most tricky one).

The resulting protocol can be very simple in the end:

A simple transport parameter is needed for each endpoint with a list of values:
  the client sends all compatible versions, with its chosen version listed first
  the server sends all versions (optionally excluding compatible versions, and always excluding versions that aren't fully deployed at the server)

Validation/negotiation is:
  the server verifies that the first version listed by the client is the version that was used by the client
  the server then chooses its most-preferred compatible version from the set provided by the client
  the client verifies that it wouldn't have chosen something different from the set provided by server

This is at least as simple as the design Christian describes.  I believe that the analysis supports the conclusion that this is secure (but it's amateur work so it's not worth much).

What I find encouraging is that this design is very flexible in terms of being able to support both compatible and incompatible negotiation while allowing progressive rollout (or rollback) of new versions.  That might mean we don't have to sacrifice flexibility or use cases at all.

On Wed, Mar 24, 2021, at 14:25, Martin Thomson wrote:
> Hey everyone,
> 
> https://docs.google.com/document/d/1HXu7LoMP8Z30JkHyMOuVOtG5W9AFOQtsL8vuSbFxXUw/edit?usp=sharing is my crude attempt at an analysis of the security of the version negotiation draft, including some suggestions that might make the protocol more efficient.
> 
> I will you reach your own conclusion, but I found some cuts that can be 
> made in the design.  Not as many as I expected originally though.  I 
> did just realize that an entire component can come out, but I haven't 
> edited it out yet; I'll leave that in case others disagree with my 
> assessment there.
> 
> It's long and complicated, sadly.  That's the one thing that I might 
> regret most about the decision to defer solving this problem properly 
> in the first place.  In any case, I hope that this is a useful 
> contribution to the discussion.
> 
> Cheers,
> Martin