On Mon, Aug 24, 2015 at 6:33 AM, David Mazieres <[email protected]> wrote: > Watson Ladd <[email protected]> writes: > >>> Actually, people have *very* strong opinions about crypto and are >>> willing to lobby pretty hard for particular algorithms and protocols. >>> We should ensure such lobbying is directed towards OS vendors *after* >>> TCP-ENO is standardized, not towards the working group beforehand (where >>> it will further slow us down undermine TCP-ENO's goal of breaking the >>> working group deadlock). >> >> Who are people? > > For example, the Russians vs. the US. The Russians require that banks > and any products purchased by the government employ the GOST cipher. In > the US, AES is effectively required. According to wikipedia, the best > known attacks on the two are roughly comparable, though GOST is easier > to misuse (by setting bad S-boxes) and has only a 64-bit block size. > > Now if I go visit a Russian bank (e.g., https://www.sberbank.ru), my > browser (which doesn't support GOST) happily chooses AES as the cipher. > Similarly, I'm sure Russian bank employees get AES when talking to US > institutions. But according to the amended "presidential decree number > 334," it seems the banks have to use GOST internally because the > Russians don't trust our crypto (which at the time of the decree was > DES, and at the time it was amended was AES). Of course, if you are > paranoid maybe you think the Russian government can break GOST and/or > the US government can break AES.
Let's look at an actual Russian bank website, and see which ciphersuites are enabled. https://www.ssllabs.com/ssltest/analyze.html?d=http%3A%2F%2Fwww.sberbank.ru%2F Please point out the GOST ciphersuite being used. Even if internal tools (which won't rely on easily disabled tcp encryption) used GOST, clearly this isn't actually applying to the website. > >> Certainly not the people willing to use the alternative algorithm if >> they have to. > > Yes the people willing to use the alternative algorithms, as evidenced > by Russian web sites willing to use AES with me. > >> The problem is with the existence of sites where only one algorithm >> must be used, and the OS is configured accordingly. > > Hard-coding global cipher priority is likely to exacerbate this problem. > If the only way to prefer GOST is to disable AES entirely, well, then > Russian institutions will disable AES. > >>> The fact that we have way too many encryption options floating around >>> does not mean all ciphersuites can be strictly ordered by security, for >>> the simple reason that nobody can predict the future. Cryptanalysis may >>> alter the relative security of different algorithms at any time. Or >>> some NIST scandal might erupt casting doubt on the design methodology of >>> P-512 compared to the nominally weaker Curve25519. At such points, OS >>> vendors need the ability to re-prioritize cipher suites without breaking >>> backwards compatibility. >> >> Am I proposing a fixed, static ordering? > > It certainly sounds like it. This is a misreading: I'm proposing that at any time there is only one suite that everyone uses, and versioning is just for transitions. > >> No. I'm proposing that in response to cryptanalysis we have a >> functional migration plan, and the negotiation mechanism to support >> it. We start with version 1, when that becomes untenable move to >> version 2. This has eliminated SSHv1 from the Internet. The >> alternative plan has never eliminated any cipher completely. > > But SSH has had the same kind of mix-and-match crypto you have been > decrying. In context, that was a good thing. For years SSH shipped a > broken stream cipher mode that used the same key in both directions. A > lot of people used SSH'S ARC4 mode because it was super fast. > Fortunately, when it was found insecure, vendors simply removed support > for that mode and security was restored where either endpoint had an > upgraded SSH. If people had disabled other modes to prefer ARC4, > obviously the upgrade path would have been much harder, as SSH would > have been unusable during the transition. No, I'm proposing introducing a new version done correctly in response. RC4 should never have been used in the first place. This migration hasn't taken place in SSL, despite a similar negotiation mechanism. > > The upgrade from SSH version 1 to version 2 was not primarily about > upgrading the encryption, was not in response to cryptanalysis, and did > not eliminate any cipher from the Internet. We could, of course, > imagine using TCP-ENO to select between the equivalent of SSH 1 and SSH > 2, with cipher negotiation handled at a different layer. But if we want > just a few good cipher suite options, then these should simply be tied > to ENO suboptions, in which case the IETF cannot prioritize these. > > David -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
