Re: [tcpinc] Summary of arguments from call

[Joe Touch <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc
>