On 23/08/2015 22:33 pm, David Mazieres wrote:
Well, hypothetically, say the US prefers spec X and the EU prefers spec
Y. The goal is that two hosts in the US would always choose spec X and
two hosts in the EU would always chose spec Y. But when a host in the
US communicates with a host in the EU, we don't really care as
much--they could choose X or Y, so we might as well base it on the
preferences of the passive opener. However, hard-coding the spec
rankings risks delaying standardization to argue over which specs should
take priority.
Again, this argument doesn't apply to TCPINC. If someone (anyone)
specifies a certain algorithm at management level, they can and should
use TLS. And, that especially applies to the banks in Russia...
The notion that someone is both specifying TCPINC and specifying
algorithm suite XXX appears too constructed to get much credence.
iang
ps; The argument doesn't apply generally either:
a. We here are far better placed to choose the Internet's crypto suite
for the general case than any manager, committee, or sysadm.
b. If the Russians don't trust it, they are entirely at liberty to write
their own crypto protocol and back-fit it into their software. It's not
that hard, and if they care - which they do for natsec - they'll be
backfitting software anyway.
c. the deployment argument wins over for the banks.
d. Unlike the WB/IMF/UN, IETF isn't a subsidy organisation to deliver
solutions to governments. It delivers to the masses, not any particular
squeaky wheel.
e. etc...
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
