FWIW, there were a number of issues raised when tcpcrypt was presented to the transport area. I haven't seen those raised here, and it would be useful to know how they affect both current proposals.
You might want to contact the TSV for that. Joe On 8/3/2015 8:15 AM, Mirja Kühlewind wrote: > Hi all, > > as promised my summary of arguments for and against a certain approach (see > below). Text in quotes is more or less copied from someone's mail as an > indication what exactly the argument was and how often this point was raised. > Not guarantee I’ve captured everything but I’ve tried my best. > > I personally would summarize this as simplicity and maturity are the main > arguments for tcpcrypt, while people at the same time are afraid that the > dependencies on TLS could hold up the work. For TCP-use-TLS the main argument > is that re-use might help to avoid bugs and make it simpler, as well as good > interactions with the higher layer TLS which may allow transition in future. > > Probably no surprising results; hope it’s still helpful for you to have the > summary below! > > Mirja > > ------------------------------------------------- > > a) TCP-use-TLS > Pro: > - re-use of existing code/mechanisms will help to avoid bugs: > - "security bugs in developing a new security protocol; less problems > than something new“ > - "TLS will ensure better and deeper security analysis“ > - "light weight filter can be smaller, and thus easier to verify, > debug, or even prove“ > - "New code is undesirable in security systems" > - re-use makes it simpler: > - "simple and direct application of TLS“ > - "better than an entirely distinct protocol" > - better interaction with/transition to use of application-layer TLS: > - "good fit for out-of-band negotiation of application-layer TLS“ > - "allows applications to seek full TLS if available and upgrade to it“ > - "TCP INC as a transition technology/simple evolution path“ > - easier to deploy: > -„more likely to achieve ubiquitous encryption because easier to deploy“ > - "TLS-the-brand is established and trusted by vendors -> acceptance > more quickly" > - can also be implemented in kernel: > - "profile of tls can be produced that will be acceptable to kernel > developers“ > - "embedded systems already do TLS in the kernel“ > - "TCP-use-TLS is not restricted to implementation in applications *or* > in user-space" > - appropriate candidate to pick one: > - "serves the purpose of opportunistic encryption“ > - "two stacks means twice the attack surface and twice the number of > security bugs" > > Contra: > - dependency on TLS and update cycles of other working group > - "opposed to putting TLS into TCP" > - "TLS is very slow to update at the institutional level“ > - "TLS depends on other WG“ > - "do not want see TCPINC and TLS1.3 tightly coupled -> can lead to > delay and friction“ > - "TLS proposal also limits the ability to make modifications because > need to interoperate w/ the TLS spec/WG“ > - can’t not be implemented in the kernel: > - "TLS not be suited for running in supervisor mode“ > - no code available/no proof of feasibility > - "TLS has only working code/substantial experience outside TCP“ > - ""passthrough" mode of TLS proposal looks unlikely to work" > - effectively there is no re-use: > - "TLS1.3 which is brand new - experience argument does not apply here" > - "codebase is going to be new anyway“ > - "likely flawed argument applies equally to both proposals“ > - should not require a userland implementation/modification > - "TLS proposal still allows for implementations to do a minimal > implementation where TLS is pushed down to userland“ > > b) tcpcrypt > Pro: > - simplicity: > - "Tcpcrypt looks much simpler“ > - "clean, tight, simple“ > - "is simpler“ > - "_simple_ protocol“ > - "simplicity“ > - "simpler" > - "a simple, easily-understood security primitive with provable > security properties“ > - "simple approach to authentication" > - running code and higher level of maturity > - "working code and experience" > - "one complete document" > - "some current runing code“ > - "started working earlier since there is more content to review“ > - "basically ready-to-go“ > - "experience of a working implementation“ > - "research on the impact on middleware boxes“ > - "the Internet-Draft is more detailed“ > - "running code“ > - ‚cleaner‘, more self-contained approach (more suitable to TCP, separation > of authentication, …) > - "more specifically suited to TCP" > - "more self-contained“ > - "a clean break with legacy systems" > - "a natural separation between application-specific authentication and > general-purpose encryption“ > - easier to implement in the kernel: > - "use in a kernel (FreeBSD) environment“ > - "more likely to make it into a kernel" > - higher chance of (quick) deployment: > - "quick adoption by major Linux distributions" > - "more likely to see actual deployment, especially in a kernel“ > - no dependencies on TLS/other working group > - "less dependence on other WGs or legacy standards/formats“ > - "isn't anchored to another working group's specification -> easier to > modify“ > - Diversity: > - "broader base of applicability" > - "experience with working on tcpcrypt will be informative (if not > followed on)" > - "adds to the diversity of protocols" > - "additional genetic diversity" > > c) both > Pro: > - "Kernel vs user space arguments aren't really important" > - "both good starting points" > - "more implementation and experimentation experience needed“ > > Contra > - "risk of nothing much happening until November" > > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
