>> I don't hear a lot of opposition to maintaining agility in ciphersuite >> preference. > > > <cough> It was discussed about 6 months to a year ago. > > The alternate -- loosely known as 1TCS or one true cipher suite -- has been > proposed on the basis that if it is ever going to be useful, then the place > it will be most useful is TCPINC. Because TCPINC is MITMable anyway, why > worry so much about the purported benefits of algorithmic agility?
You may have an argument for a minimal implementation of the WG's goals, but both TCP-ENO/tcpcrypt and TLS-over-TCP are trying to achieve a solution for opportunistic encryption that is also the basis for an authenticated channel for applications that want the upgrade against active attacks. If, in the case of tcpcrypt, the cipher suite is chosen by the kernel at connection time before the application is even told that the connection has been established, then it's critical for that cipher suite to be secure against active attacks in the presence of endpoint authentication. Best practice here is that it be upgradeable, because nothing is secure forever. Strictly speaking, I think the 1TCS notion is *possible*, but there's simply no way to rule out future revolutions in cryptanalysis. > However basic IETF consensus or practice is that protocols maintain agility, > and there is a coming draft on that. Agreed in principle, but can you be more specific on this draft? Kyle _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
