Hi David, I don’t have anything against public-key encryption, and there are various ways it can be (efficiently) implemented in either a symmetric fashion or as a “special-case asymmetric optimization” as discussed already, so I’m not going to address all your individual points about that. Just...
On Nov 7, 2015, at 5:32 PM, David Mazieres <[email protected]> wrote: > Bryan Ford <[email protected]> writes: >> Especially when preserving role-symmetry makes the protocol simpler >> and cleaner, as I think it does. > > I also disagree about making the protocol simpler. Also, even if you do > think the protocol is simpler, the API is more complicated, and that is > likely to be the biggest source of errors. One important and readily measurable it will make the protocol simpler (at least in the purely symmetric version) is by simplifying the control flow of any implementation. In most software complexity metrics, number of if-statements and other control flow cases play a major role. The symmetric tcpcrypt design I proposed, as far as I can tell, removes all the “if” statements of the form “if I am in the A-role do this” or “if I am in the B role do that”. I’m sure there are some number of those in your tcpcrypt implementation(s); I don’t know how many but maybe you can tell me. :) As far as I can tell, the symmetric design removes all those if-statements, and adds no other essential ones that I can think of. Can you point out any conditionals or special-cases that the symmetric design requires and the asymmetric design does not? > It seems ridiculous to rule out efficient use of public key encryption, > including post-quantum crypto, which may well be important someday, in > favor of simultaneous open, which already basically works with ENO, > would likely never be used with ENO anyway, and will grow even less > relevant with IPv6 adoption. I’m not remotely proposing to rule out efficient use of public key encryption. As I said already, if you want it (which is fine), it can easily be added as a special-case, optional asymmetric optimization that gets activated when both parties support it and happen to agree on who is A and who is B (which will be most of the time). But if it doesn’t work, it simply falls back to the slightly-less-optimized symmetric method. You get your efficient use of public key encryption, and we avoid breaking TCP’s role-symmetry or simultaneous open. B
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
