Re: [quicwg/base-drafts] Simplify version negotiation (#2133)

[MikkelFJ <[e-mail]>]

I must say that I was not fond of the positive/negative list juggling in the previous approach, and the potential for missing attack vectors or making implementation mistakses, but I also do find current vneg complex.

What is the thinking on downgrade attacks?

Consider babyalarm / widely deployed IoT device offering 3 versions A, B, and C. Later it turns out version B is broken. Compromised MITM device plays valid endpoint and selects version B. Real server cannot ignore version B because MITM got in the way. Not sure the current state is much better on this account?

I good thing about client publishing versions is that a constrained device can offer versions in order of preference rather than conservatively choosing what is likely supported. Likewise an advanced client could prefer unlikely new version, but offer the common version also.

Resolving preferences becomes a bit more involved when the server also has a preference that is not necessarily aligned with the clients. For example servers may prefer AES acceleration over a ChaCha only version (I know TLS is also negotiating crypto - but why, really?).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2133#issuecomment-446770619